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ABSTRACT:  This  is  a  proposal  and  design  study  for  a  system  of  programs 
which  will  create  and  animate  two  dimensional  line  drawings  inter¬ 
actively.  The  system  allows  the  user  to  create,  manipulate  and 
animate  both  simple  and  hierarchically  structured  pictures;  to 
create  his  own  special  purpose  programs  to  extend  the  system  and 
to  store  large  quantities  of  data  in  a  compressed  form  in  picture, 
scene  and  film  libraries.  The  thesis  concentrates  on  two  major 
system  design  aspects:  data  structures  and  man/machine  interface 
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CHAPTER  I 


INTRODUCTION 


’’Machines  are  more  than  they  seem” 

Marvin  Minsky 

This  thesis  proposes  a  computer  software  system  for  the 
interactive  creation  and  animation  of  two  dimensional  line  drawn 
figures.  It  departs  from  other  systems  discussed  in  the 
literature  (ey .  1 , 6,  19 , 22,  25 ,29 , 34 )  not  so  much  in  its  aims  and 
goals  as  in  its  methods  and  internal  structures.  The  emphasis 

is  on  the  need  for  a  system  which  allows  the  user  to  create  and 

/ 

manipulate  articulated  figures  in  such  a  way  that  motions  can  he 
napped  from  one  figure  to  a  similarly  structured  figure.  This 
proposal  is  a  detailed  practical  suggestion  as  to  how  such  a 
system  can  be  built.  some  of  the  ideas  (  see  the  conclusions: 
chapter  5  )  have  been  tested,  but  basically  this  is  a  pre¬ 
programming  sytem  design  study.  The  equipment  in  mind  is  an  IEM 
360/44  with  tapes,  disks,  card  reader,  line  printer,  display 
scope  (plus  function  key  board  and  console)  and  micro-film 
plotter  (a  calcomp  R35)  and  the  language  of  implementation  is 
expected  to  be  FORTRAN  or  PL/1  except  for  some  routines  (I/O  for 
example)  which  are  more  efficiently  coded  in  ASSEMBLY  language. 

The  technologies  of  computing  and  film  making  have  been 
moving  closer  since  the  early  1S50's.  So  far  the  computer 
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synonymous  (except  for  educational  films)  and  animation  can 
scarcely  claim  to  be  a  fully  developed  and  flourishing  art 
f  ora . 


The  hand-drawn  animated  film  of  cartoon  or  entertainment 
variety  reached  its  zenith  of  popularity  in  the  1930*s  at  the 
hands  of  Walt  Disney.  The  essential  limitations  of  hand  drawn 
animation  combined  with  rising  production  costs  and  a  growing 
demand  in  the  television  world  for  shorter  production  times  have 
driven  post-war  animators  to  seek  every  conceivable 
simplification  and  shortcut  from  the  actual  drawing  to  the 
production  stage.  This  process  has  been  carried  to  the  point 
that  some  animators  today  actually  adopt  their  current 
exigencies  as  a  necessary  esthetic  standard.  This  confusion  of 
simplicity  with  animation  will  on  the  whole  tend  to  produce  an 
excessively  stylized  creation.  Although  there  exist  always  a 
few  individuals  capable  of  powerful  ana  original  contributions 
to  animation,  I  feel  that  significant  artistic  breakthroughs  are 
far  more  likely  to  occur  if  and  when  an  entirely  new  tool  is 
created  to  enable  the  creation  of  animated  film.  And  to  date 
the  general  purpose  digital  computer  holds  the  best  (if  not  the 
only)  prom  ise  of  providing  such  a  tool.  The  ultimate  hope  which 
I  share  with  others  in  the  field  of  computer  animation  is  to 
relate  the  animator  to  his  film  footage  with  an  immediacy 
comparable  to  that  which  a  painter  or  musician  shares  with  his 
medium. 
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Since  one  painting  of  significance  will  often  occupy  its 
creator  for  a  period  of  days,  weeks  or  even  months  it  is  evident 
that  in  hand  drawn  animation  to  produce  the  24  picture  per 
second  required  for  motion  will  require  incredible  sacrifices  to 
detail  and  probably  (though  not  necessarily)  to  quality  as  well. 
Even  with  the  resources  of  a  large  animation  studio  it  is 
necessary  to  evolve  an  elaborate  set  of  simplifications  of  form, 
color  and  motion  with  prime  emphasis  on  the  motion's 
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In  other  words 

this  thesis 

represents  an  attempt  to  remove  some  of  the  technological 
limitations  that  constrain  the  animator. 

In  attempts  to  speed  up  the  process  of  animation  or  reduce 
the  tedium  (depending  upon  how  you  choose  to  see  it)  three 
approaches  may  be  distinguished: 

1)  special  effects  (which  may  include  a  wide  and  versatile 
set  of  possible  picture  motion  types)  dependent  upon 
analogue  devices; 

2)  digital  computer  control  of  the  animation  stand  and 
perhaps  also  of  the  editing  process; 

3)  digital  computer  control  of  the  image  itself. 

Examples  of  techniques  capable  of  producing  animated  human 
figures  in  category  (1)  above  are  Lee  Harrison  of  Computer  Image 
Corporation  with  his  " sy nt hesyzing  skin”  process  (see  ref(1). 
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The  limitations  of  approach  (2) 
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greatest  gains  for  the  animator  may  ultimately  lie  (especially 
for  artistic  applications)  with  the  area  approach  since 

1)  this  device  lends  itself  more  readily  to  treatment  of 
areas  and  textures; 

2)  the  hidden  line  problem  is  less  difficult  to  resolve  in 
a  number  of  cases  and 

3)  the  use  of  colour  can  be  readily  invoked  by  means  of 
existing  TV  technology. 
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ever,  the  vector  or  line  drawing  approach  is  the  one 
here  simply  because  the  equipment  is  available  at  the 
ty  of  Toronto  and  is  more  commonly  available  everywhere 
ster-scan  devices.  A  number  of  computer  animation 
have  been  developed  of  late  which  deal  with  the  problem 
nd  3  dimensional  line-drawings.  These  systems,  such  as 
(Per  nsler ,  Volence  1969)  which  has  achieved  some 
al  success,  still  do  not  allow  the  user  to  create  human 
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ive  features  to  enable  the  user  to  specify  the  picture 
as  well  as  the  picture  elements.  More  recently,  work 
reported  from  the  University  of  Waterloo  (Savage,  Cook 
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and  Constant  1971)  and  the  University  of  Pennsylvania 
al  1971)  along  somewhat  similar  lines  to  this  proposa 
goals,  different  methods.  Eany  of  the  differences  st 
desire  to  deal  with  articulated  figures  and  their  mot 
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5)  He  will  have  the  ability  to  create,  modify  and  delete 
scenes  using  the  above  capabilities  and  store  and  retrieve 
them  from  a  library  ot  scenes. 

6)  He  will  have  the  power  to  preview  sequences  and 
segments  of  scenes  at  will. 

7)  The  commonly  used  motions  of  articulated  figures 
(walking  etc.)  will  be  applicable  upon  simple  command  to 
any  of  a  whole  related  set  of  pictures  so  that  frequently 
used  motions  need  be  created  only  once. 

8)  The  data  will  be  stored  whenever  possible  in  a  compact 

form  to  allow  temporary  and  permanent  storage  of  a  large 
and  useful  number  of  pictures,  sequences  and  scenes  for  the 
creation  of  movies.  The  need  for  a  data  structure  of  films 

which  avoids  redundancy  can  be  seen  by  the  following 

calculations.  If  we  allow  an  average  of  500  data  points 
per  frame  of  film,  then  at  24  f r ames/second  a  minute  of 
film  would  require  at  10  bytes/point  24x60x500x10=7. 2M 
bytes  of  space!  For  this  reason  considerable  thought  has 
gone  into  storage  efficiency  although  not  to  the  extent  of 
word  compression  since  that  would  complicate  implementation 
and  expansion  of  the  system  to  an  undesirable  and  probably 
unjustifiable  degree  at  this  stage.  The  creation  of  the 
actual  output  frame  data  is  normally  delayed  until  the  last 
possible  moment  -  the  only  exception  being  those  instances 
in  which  a  user  for  some  special  reason  may  want  to  preview 

a  completed  portion  of  a  scene  in  full  detail  on  a  TV-type 

display  (eg. IBM  2250). 
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CHAPTER  IT 
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implemented, 
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apter  presents  a  general  survey  or  overview  of  the 
hapter  3  goes  into  detail  on  the  interaction 
nd  data  structures  and  chapter  4  presents  a  scenario 
te  the  detailed  use  of  some  of  the  system’s  features 
some  estimated  performance  figures. 
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as  creating  an  imaginary  animation  machine  as  shown 
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Id  have  a  means  of  distinguishing  ’’depth”  for  hidden 
1  should  hidden  line  removal  algorithms  be 
However,  since  there  is  no  desire  to  get  involved 
f  3-D  animation  (see  reasons  below)  it  was  decided 
ese  cels  arbitrarily  close  (zero  effective  vertical 
f  cel  levels)  and  hence  ignore  parallax. 
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THE  SEPARATION  OF  CEN  N  AND  CEL  n  +  1  IS  ZERO 


FIG.  2.1 
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ystem  could  be  provided  with 
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The  data  organization  of  the  elements  comprising  a  film  are 
given  in  simplified  fora  in  figure  2.2.  Briefly,  from  top  to 
bottom  we  see  that  filias  are  comprised  of  scenes  which  in  turn 
contain  both  "activities”  and  "camera  instructions"  (definitions 
on  pg.  47ff) .  Either  of  the  entities  "activities"  or  "camera 
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instructions"  may  reference  a  "control  curve".  An  activity  is 
composed  of  sequences  which  are  in  turn  composed  of  pictures. 


At  level  1  in  the  figure,  the 
system  are  two-dimensional  and  a 
where  i  is  an  "intensity  factor"  or 
For  this  proposal,  i  is  simply  tre 
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2-D  coordinates  was  predicated  upon 
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Accordingly,  3-D  represents  an 
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to  complicate  it. 
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2)  Picture  manipulations  of  1440  f raraes/mi nute  consume 

i 

large  computer  resources  (compute  time,  core  storage, 
secondary  storages  and  I/O  time).  The  2-D  case  is  both 
simpler  and  cheaper  on  all  counts. 

A  collection  of  2-D  coordinates  (referred  to  the  center  of 
the  "table"  in  fig.  2.1  as  origin)  constitute  an  unstructured 
picture  (or  UPIC  for  short) .  Such  entities  can  be  used  for 
storing  backgrounds,  sub-pictures  of  what  is  to  be  a  larger 
structure,  titles  or  other  textual  material,  mathematical 
curves,  graphs  etc.  Should  the  user  wish  to  freguently  rotate  a 
UPIC  about  some  particular  point,  he  may  designate  this  as  the 
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"pivot  point”  which  will  then  be  stored  in  a  specific  location 
within  the  UFIC  array.  Since  the  UFIC  may  be  used  as  a  sub- 
picture  in  a  larger  picture,  the  user  may  wish  to  specify 
certain  "attachment  points"  or  points  to  which  other  UPICS  may 
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and  the  set  of  attachment  points 
ints"  for  the  UPIC.  The  user  is 
ore,  retrieve,  manipulate,  draw, 
data  points  other  than  the 
sh  points".  Both  types  may  be 
Finally,  the  vectors  joining 
ereas  those  joining  the  pivot  to 
skeleton"  of  the  UPIC.  This 
user  to  be  visible  or  not  -  the 
le  skeletons  on  the  scene  or 
visible  skeletons  at  the  picture 


These 

UPICS 

may  be  grouped 

together  to 

for  m 

a  struct 

picture 

(SPIC) 

which  can 

be  manipu 

la  te  d 

as  a  wh 

Furthermore,  the  UPICS  comprising  a  SPIC  may  be  grouped  together 
and  "joined"  by  affixing  the  pivot  point  of  one  UPIC  to  one  of 
the  hinge  points  (which  may  be  the  pivot  point)  of  another  UPIC 
to  form  a  "hinge"  about  which  rotation  can  occur.  If  an  entire 
SPIC  is  to  be  rotated,  it  is  rotated  about  a  user  selected  pivot 
point  which  can  be  anywhere  in  the  plane  of  the  table.  The 
structure  of  these  SPICS  is  basically  tree-like  with  pointers 
from  any  one  UPIC  to  its  "father",  "son"  and  "brother"-  these 
being  defined  as  follows: 
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The  example  of  figure  2.3  should  clarify  these  definitions. 
It  shows  a  structured  picture  S  in  fig.  2.3  (a)  and  the 
structural  connections  in  fig.  2.3  (c) .  Fig.  2.3  (d)  is  an 
equally  valid  alternative  to  2.3(c)  and  in  fact  many  variations 


are  possible 

.  If  A  in  thi 

s  example  is 

the  TORSO 

of  a 

man 

then 

it  would  be 

the  logical  ch 

oice  for  the 

uppermost 

node 

(the 

first 

father  node  of  the  tree)  since  when  the  user  moves  the  torso, 
the  rest  of  the  body  should  also  move  in  most  cases. 


Thus  the  user  may  create  a 
a  given  number  of  UPICS  (a  numbe 
of  SPICS  allowed  by  the  system) 


he  desires.  These  structured 


regard  to  their  data  structure 
handle  the  case  of  an  articulat 
constituent  arms,  legs  etc.  The 
between  sub-pictures,  add,  de 
translate,  scale)  them  and  even 
structured  picture  to  another 
specifying  only  the  pivot  points 


very  large  number  of  SPICS  from 
r  limited  by  the  number  of  names 
and  may  modify  this  structure  if 
pictures  were  designed,  with 
and  consequent  properties,  to 
ed  figure  such  as  a  man  with  his 
useL  can  relocate  pivot  points 
lete,  modify  and  move  (rotate, 
transpose  sub  pictures  from  one 
.  Ey  the  simple  expedient  of 
and  requesting  that  the  pivots 


UPICS  :  A,B,C,D 

FIG.  2.3  (a) 


NODE  STRUCTURE  IN  FIGS.  2.3  (d) 

AND  2-3  (c) 
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FIG.  2.3(b) 


N  :  name  of  this  UPIC  node 
FN  :  pointer  to  the  UPIC  to  which  N 
is  attached  ("father  of  N") 

SN  :  pointer  to  any  one  of  the  UPICS 

attached  directly  to  N  ("sons  of  N") 
BN  :  pointer  to  another  UPIC  which  is 
also  attached  to  N  ("mother  of  N") 
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STRUCTURE  OF  THE  SPIC  IN  FIG.  2.3(a) 


AN  ALTERNATIVE  STRUCTURING  OF  THE  UPICS 

IN  SPIC  S 


FIG.  2.3(c) 


FIG.  2.3(d) 
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he  needs.  (Any  data  entity  wh 
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A  is  a  set  °f  pictures  (UPICS  or  SPICS)  each  of 

which  usually  differ  in  some  respect  from  those  adjacent  to  it 
so  that  when  viewed  at  24  per  second  motion  is  perceived.  These 
differences  may  result  from  a  transformation  of  picture  shape  or 
a  rearrangement  of  the  sub-pictures  of  a  picture  (as  in  a 
walking  man).  It  must,  however,  be  noted  that  although  a 
sequence  is  logically  equivalent  to  a  picture  set,  it  is  not 
identical  to  it.  This  is  because  a  sequence  is  stored  as  a  set 

t 

of  instructions  telling  the  system  how  to  create  the  sequence 


and 

hence 

until 

t  he 

request  for  a  display  of  the 

sequence,  it 

need 

only 

exist 

as 

one  of  several  possible 

”poten tial" 

sequences. 

Some 

segue 

nces  will  be  cyclic  in  that 

the  first  and 

last  frames  can  be  made  smoothly  adjacent  if  projected  in 
succession,  others  will  not  be  cyclic. 


A  cyclic  sequence  is  thus  one  such  that  if  it  consists  of 


frames 


pi  jp  2  p3  p*  p5  F6  F7 


Fn 


and  if  the  sequence  of  frames 
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F 1  ....Fn  F  1  F2  ....Fn  Fl . - • .  etc 

are  projected  as  a  movie,  the  motion  resulting  from  viewing  the 
movie  will  be  repetitive  and  smooth.  In  particular  Fn  Fl  will 
show  no  "flicker" ,  "jump”  or  "discontinuity"  as  they  are 
successively  projected  on  the  screen.  It  is  up  to  the  user  to 
know  whether  it  is  or  is  not  cyclic  in  keeping  with  a  desire  to 
avoid  taking  excessive  responsibility  upon  the  system  and 
thereby  creating  an  unwieldy  and  complex  system. 

One  final  comment  on  sequences  and  a  very  important  one  is 
that  for  sequences  built  out  of  structured  pictures  with 
skeletons  it  is  possible  to  store  the  motion  in  an  angle  table 
by  recording  all  the  angular  skeletal  positions  of  sub-pictures 
for  each  frame.  Consequently  it  is  possible  to  map  a  motion 
from  one  sequence  to  any  related  SpIC  to  create  a  new  sequence 
with  the  same  motion  but  a  different  SPIC.  For  example,  create 
an  articulated  WAN  (a  SPIC),  create  a  RUNNING  sequence,  create  a 
HOMAN  and  then  by  a  simple  mapping  command  create  a  new  sequence 
WOMANRUN. 

At  the  next  level  of  the  data  hierarchy  we  find  the  two 
elements  of  any  scene:  a  set  of  "activities"  and  a  set  of 
"camera  instructions".  An  activity  is  an  instance  of  the  use  of 
a  sequence  for  a  specific  number  of  frames  in  a  scene.  In 
effect,  an  activity  is  a  set  of  conditions  established  (usually 
interactively)  by  the  user  to  tell  the  system  that  a  certain 
sequence  (such  as  HANRUN)  is  to  be  used  starting  at  frame  nO  and 
used  cyclicly  until  nf;  that  the  sequence  has  initial  and  final 
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locations  specified  by  the  user  as  well  as  initial  and  final 
size  and  angular  placement.  Activities  can  overlap  to  any 
degree  and  any  number  of  activities  (overlapping  in  time  and/or 
space  or  not)  may  refer  to  the  same  sequence.  Thus  a  given 
sequence  can  appeal  in  the  same  scene  or  even  the  same  frame 
many  times.  Thus  a  given  frame  of  the  final  scene  might  contain 
many  copies  of  a  particular  frame  of  the  same  sequence  (e.  g. 
an  army  of  men).  Furthermore,  the  activity's  parameters,  if 
desired,  can  specify  interpolation  from  nO  to  nf  of  rotation, 
scaling  and/or  translation  by  means  of  "control  curves".  For 
example  a  translation  control  curve  would  mark  the  path  to  be 
followed  by  the  referenced  sequence  and  the  rate  at  which  it  was 
to  be  followed  would  be  given  by  the  density  of  points  along  the 
curve  -  the  closer  the  points,  the  slower  the  motion  along  the 
curve. 
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Given  that  a  particular  motion  sequence  is  to  occur  in  a 
scene,  it  is  somewhat  arbitrary  (i.e.,  there  is  overlap  and  the 
user  makes  up  his  own  mind)  as  to  what  parts  of  the  motion 
belong  to  the  sequence  and  what  components  are  given  ever  as  the 
property  of  the  activity  which  uses  that  sequence  to  produce  the 
final  motion*  In  general,  we  can  say  this  much.  Any  motion  on 
a  screen  can  be  considered  as  having  two  parts: 

-  an  invariant,  perhaps  repetitive,  internal  motion; 

-  overall  changes  of  size  and  position  peculiar  to  the 
application . 

In  other  words,  if  a  man  is  running  across  a  screen  his 
global  or  invariant  property  would  be  running  {as  though  his 
centre  of  gravity  were  fixed)  and  his  local  changes  from  frame 
to  frame  would  be  the  unique  changes  of  attitude,  size  and 
location  in  that  particular  instance  of  his  running.  The 
invariant  properties  are  thus  usually  given  over  to  sequences, 
the  local  properties  to  activities. 

"camera  Instructions"  are  fairly  self  explanatory  in  aim: 
the  user  at  the  display  scope  is  allowed  to  decide  exactly  how 
the  camera  is  to  be  used  in  viewing  and  filming  the  activities 
comprising  a  scene.  For  this  purpose,  control  curves  are  also 
used  in  a  manner  similar  to  the  way  they  are  used  by  activities. 
Thus  the  camera  can  be  set  to  pan,  zoom,  follow  a  path  (control 
curve)  at  specified  interpolation  rates  {  related  to  the  path's 
point  density),  track  some  specific  activity. 


etc 
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When  the  user  first  enters  the  mode  which  allows  him  to 
manipulate  and  set  up  the  contents  of  a  scene,  he  is  faced  by  a 
view  of  the  table  and  can  use  the  function  key  board  (FKB)  to 
move  the  camera  and  hence  change  the  view  -  this  is  known  as 
"free  -  viewing"  which  is  to  be  distinguished  from  "controlled  - 
viewing"  in  which  the  camera  moves  according  to  the  table  of 
camera  instructions. 

To  summarize  the  activity  creation  process: 

1)  name  the  activity’s  sequence; 

2)  specify  (draw  and  position)  E°,  the  initial  envelope 
into  which  the  sequence  must  fit; 

3)  specify  Ef  ,  the  final  envelope; 

4)  specify  f°  and  £f,  the  initial  and  final  frames  in  the 
scene  at  which  the  activity  is  to  appear; 

5)  specify  the  manner  in  which  the  sequence  is  to  be 
interpolated  as  E°  moves  into  Ef  with  regard  to: 

tra  nsla tion 
rotation 
sea  ling . 

This  interpolation  may  be  linear,  independently  non  linear 
or  the  translation  and  rotation  may  be  interdependent  (see 
chapter  3) . 

The  process  of  creating  camera  instructions  is  very  similar 
to  that  of  creating  activities  except  that  the  envelopes  are 
empty  and  simply  define  that  area  of  the  table  which  will  fill 


the  screen. 
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When  a  complete  set  of  activities  and  camera  instructions 
have  been  created  to  the  user’s  satisfaction,  he  may  store  them 
as  a  scene  in  the  scene  library  and/or  output  it  to  the  micro 
film  plotter.  At  level  5  in  fig  2.2  one  is  simply  manipulating 
the  names  in  an  ordered  list  of  scenes  which  constitute  a  film. 

Now,  as  far  as  the  output  of  a  film  is  concerned,  all  we 
need  is  the  picture  library  plus: 

1)  a  sequence  table  which  indicates  how  the  software  can  (a) 
select  a  sequence  directly  from  PICLIB  or  (b)  create  a 
sequence  by  manipulating  entries  in  PICLIB; 

2)  an  activity  table  to  specify  how  the  various  members  of 
PICLIB  are  to  be  placed  on  the  animation  stand's  "table" 
for  any  given  frame; 

3)  a  camera  instruction  table  to  position  the  camera  for 
each  shot  in  the  scene; 

4)  a  scene  index  which  merely  refers  to  the  pair  of  tables 
in  (2)  and  (3)  for  each  scene  stored  in  the  system’s 
libraries ; 

5)  a  film  index  which  gives  an  ordered  list  of  scene  names 
for  each  film. 

This  approach  allows  the  storage  of  considerably  more  film 
footage  in  core  and  on  secondary  storage  devices  than  if  we 
tried  to  store  each  frame  or  even  every  second  or  third  frame 
(later  chapters  present  the  argument  for  this  in  greater  detail: 
see  chapter  3).  However,  note  two  points:  first,  the  above  is  a 


slightly  idealized  version  of  the  storage  as  we  shall  see 


m 
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chapter  3  and  secondly,  there  will  frequently  arise  times  when 
the  user  will  find  it  useful  to  view  segments  of  the  film  in 
motion,  prior  to  its  output  on  the  micro-film  plotter.  Hence 
storage  must  be  set  aside  on  disk  for  completed  frames  and  a 
reference  system  set  up  to: 

1)  prevent  the  system  ever  calculating  the  same  frame  twice 
as  could  occur  with  overlapping  scene  segments. 

2)  allow  the  system  to  free  for  an  overwrite  any  frame  on 
disk  as  seen  as  it  becomes  modified  in  any  way  and  hence 
obsolete  (or  at  least  before  the  next  output  of  frames  to 
disk)  . 

Such  frames  stored  on  disk  as  pre-computed  buffer  loads  for 
the  graphic  display  device  (e.g.,  IBM  2250)  can  be  output  for 
viewing  at  rates  approximating  24  frames/sec  (or  slower  if 
desired) .  How  close  to  24fps  the  display  runs  depends  upon  the 
complexity  of  the  picture  and  the  amount  of  2250  core  it  is  to 
occupy.  The  former  determines  the  time  to  generate  the  picture, 
the  latter  the  time  to  load  the  display  buffer.  To  save 
computation  time  the  user  might  choose  to  view  every  nth  frame 
of  the  motion  and  hence  change  frames  every  n/24  seconds. 

An  example  is  now  presented  to  give  a  simple  but  clear  idea 
of  the  basic  notion  of  picture,  structured  picture,  sequence, 
activity,  camera  instruction  and  scene.  The  details  of  these 
ideas  and  their  structures  are  given  in  chapter  3. 

Suppose  a  user  wishes  to  create  a  scene  in  which  a  man  runs 
from  left  to  right  across  the  screen  and  simultaneously  shrinks 
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in  size.  First  of  all  a  series  of  unstructured  pictures 
are  created,  perhaps:  TORSO,  THIGH,  CALF,  FOOT, 
LOWER ARM .  This  structural  breakdown  is  now  used  to  c 
structured  picture  (SPIC)  called  MAN  where  the  STIC  arra 
simply  a  table  of  pointers  which  show  the  system  how  MAN 
be  built  up  from  the  11PIC  members. 
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Now  the  user  is  ready  to  look  at  the  overall  scene  action 
and  for  this  he  creates  the  activity  (ACT)  in  which  the  sequence 
RON  starts  at  the  left  side  of  the  screen  and  moves  to  the  right 
while  simultaneously  shrinking  in  stature.  To  create  this 
activity,  RETREAT  say,  the  user  merely  provides  the  following 
data : 

1)  the  SPIC  name,  MAN 

2)  the  starting  size,  position,  attitude  and  frame  number 
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(relative  to  the  start  of  the  scene) 

3)  the  final  size,  position,  attitude  and  frame  number. 


Finally,  the  user  must  tell  the  system  how  to  put  this 
scene  onto  film  by  providing  "camera  instructions”.  In  this 
case  he  could  simply  ask  the  camera  to  hold  the  entire  field  in 
view  throughout  the  scene.  however  he  might  also  have  asked  the 
camera  to  track  the  figure  at  say  2/3  of  its  speed  sc  that  it 
would  move  oft  screen  more  slowly.  And  in  this  last  remark  we 
see  a  primary  advantage  to  the  overlap  between  the  ideas  of 
sequence,  activity  and  camera  instructions:  at  each  stage  in 
creating  a  scene ,  from  segue  nee  to  activities  to  camera 
instructions  the  user  can,  without  modifying  his  previous  work, 
reshape  his  original  conception  of  the  result.  Thus  the  first 
iteration  itself  allows  internal  reshaping  and  interactive 
aodif ica tion  of  the  final  image. 


The  details  of  the  user  instruction  procedures  -  the  manner 
in  which  the  user  inputs  his  decisions  and  requests  to  the 
system  and  the  formats  of  the  results  presented  to  the  user  by 
the  system  are  given  in  appendix  A . 
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CHAPTER  III 


DETAILS  OF  DATA  STRUCTURES  AND  THEIR  USES. 


The  general  structure  of  the  system's  data 
figure  3.1  where  we  observe  the  following: 

A  unstructured  picture  library 
E  structured  picture  library 
C  sequence  library 
D  angle  table  library 
E  activity  table  library 
F  control  curve  library 


base  is  shown  in 

UPIC.LIE 
SPIC  .LIB 
SEQ. LIB 
ANGT.LIE 
ACT. LIE 
TCC . LIB 


RSCC.LIE 


G  camera  instruction  table  library  CIT.IIB 

H  scene  table  library  SCNT.LIB 


The  following  indexes  are  needed  to  access  the  data  in  the 
above  libraries: 

IA  UPIC. INDEX 

IB  SPIC. INDEX 
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I-I|nstructured_Pictures _ [U  PICS]__an  d 

B_St r uc tu red_Pi ct ur es _ (SPICS) 

Ideally  we  might  require  the  following  properties  of 
pictures  in  an  animation  system: 

1)  the  ability  to  create,  modify  and  delete  any  sub-picture 
of  a  complex  picture  on  an  interactive  display  device; 

2)  dynamic  allocation  and  freeing  of  core  to  correspond  to 
the  activities  in  ( 1)  ; 

3)  the  power  to  create  structured  pictures  from  both  simple 
pictures  and  other  structured  pictures  and 

4)  to  indicate  (perhaps  by  light  pen)  the  point  of  contact 
(hinge)  between  two  adjoining  picture  elements  or  to  move 
or  delete  that  point  of  contact; 

5)  ability  to  control  parameters  of  a  li ne *s  (vector * s) 

appearance  such  as  its  visibility  or  intensity,  its 
thickness  and  its  texture  (dotted, solid, dashed, ragged, 

etc,),  and  finally 

6)  the  ability  to  retrieve  and  store  these  structures  in 
such  a  way  that  neither  core  nor  disk  space  is  wasted  by 
repetetive  storage  of  identical  sub-pictures. 

These  desires  must  be  balanced  against  implementation 
difficulties  and  the  requirement  that  the  bulk  of  the  system 
should  be  written  in  a  higher  level  language  (FORTRAN  or  PL/1 
for  example)  to  speed  up  implementation  time,  facilitate 
debugging,  facilitate  user  comprehension  and  thereby  enable  the 
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user  to  both  use  the  system  eff 
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whenever  either  bound  was  exceeded  i.e.,  anytime 
♦SOWS  NEEDED  >  #ROKS  (ALLOWED  FOR) 
or  tHINGES  USED  >  # HIN GES ( ALLOWED  FOR ) 
holds. 


The  first  row  of  the  UPIC  array  consists  of  four  integer 
halfwords  to  indicate: 

1)  the  #  of  rows  allowed  for  by  the  array 

2)  the  #  of  rows  used  by  the  array 

3)  the  #  of  hinges  allowed  for  by  the  array 

4)  the  #  of  hinges  used  by  the  array 

The  fifth  halfword  is  not  used. 
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Sincjej.  a  permanent  pivot  point  of  a  picture  element  which 
will  usually  (by  default)  be  invisible  on  the  final  fils 
output. 

I!!£sh_poin ts_:  those  points  of  a  picture  which  are  intended 
to  be  seer.  in  the  final  output  (usually  all  the  picture 
points  minus  the  hinges) . 

S]S§ieton^  a  vector  drawn  between  the  first  two  hinge  points, 
should  two  ct  more  exist. 
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A  few  points  should  be 
skeleton.  First  of  all, 
pivot  points  and  hence  only 
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every  rotation  will  require  a  translation  prior  to  the  rotation 
in  order  to  place  the  centre  of  rotation  temporarily  at  the 
origin. 

When  two  or  more  UPICS  are  to  be  regarded  as  subpictures 
constituting  a  larger  picture,  the  larger  picture  is  called  a 
structured  picture  or  SPiC.  Thus  a  SPIC  may  be  constituted  in  a 
number  of  ways  as  was  suggested  in  figure  2.3.  When  a  user 
requests  a  display  of  a  structured  picture,  first  of  all  a  SPIC 
array  is  retrieved  from  the  SPIC. LIB.  The  layout  of  the  array 
is  shown  in  figure  3.4.  The  array  is  eight  integer  halfwords 
wide  and  the  desired  number  of  rows  deep.  The  first  row  only 
utilizes  eight  bytes: 

1)  the  #  of  rows  in  the  array  (  2  bytes  )  ; 

2)  the  #  of  rows  actually  used  (  2  bytes  ); 

3)  a  continuation  pointer  to  the  address  of  the  next  array 
in  case  of  overflow. 

Property  (1)  is  provided  by  the  user  as  a  direct  function 
of  his  estimate  of  the  greatest  number  of  nGdes  in  the  SPIC 
array.  Allowances  for  dynamic  expansion,  allocation  and 
deallocation  of  core  for  SPIC  arrays  would  be  similar  to  that 
for  U PIC  arrays  (see  pgs  33,  34),  except  that  there  is  room  in 
row  one  for  the  pointer  to  the  continuation  array.  The  linkages 
contained  in  a  SPIC  array  are  shown  in  figure  3.5.  Here  we 

observe  that  each  node  of  the  SPIC  structure  is  comprised  of  six 

data  elements: 

1)  N:  the  name  of  the  node  which  is  either  the  UPIC  name  or 
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The  labels  (except  for  HFN)  correspond  to  those  in  Figure  2.3  and 
have  the  following  meaning: 


N  :  name  of  a  UPIC  (6  bytes) 

FN  :  pointer  to  the  row  which  contains  N' s  father  (1  byte) 

SN  :  pointer  to  the  row  which  contains  a  son  of  N  (1  byte) 

HFN  :  pointer  to  the  row  in  the  UPIC,  FN,  which  contains  the  hinge  to 

which  the  pivot  point  of  N  must  be  attached 

BN  :  pointer  to  the  row  which  contains  a  brother  of  N  (1  byte) 


LAYOUT  OF  A  SPIC  ARRAY 


FIG.  3.4 
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FN,  SN,  HFN,  BN  are  explained  in  Fig.  3.4 


NODE  STRUCTURE 


FIG.  3.5 
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else  a  label.  A  label  is  simply  the  name  of  a  group  of 
CPICS  -  more  of  this  later. 

2)  FN:  a  pointer  (an  integer)  to  the  row  in  this  SPIC  array 
which  contains  the  "father"  UPIC  i.e.,  the  UPIC  to  which 
this  one  is  attached. 

3)  HFN:  a  pointer  to  the  hinge  (an  integer  i  means  the  hinge 
is  in  row  i)  of  the  father  UPIC  to  which  this  UPIC  is  to  be 
attached.  This  is  called  the  "attachment  point". 

4)  SN:  a  pointer  to  the  "eldest  son"  node.  This  is  in 
practice  usually  the  first  node  which  the  user  has  chosen 
to  attach  to  this  one.  Any  other  nodes  he  attaches  to  this 
one  will  be  found  by  "pointer  chasing"  all  the  brothers  of 
the  eldest  son  node. 

5)  BN:  a  pointer  to  the  "eldest  younger  brother"  of  this 
node. 

An  examination  of  figures  3.6a,  3.6b  and  3.7  will  help 

i 

clarify  the  use  of  these  pointers.  To  return  to  the  notion  of  a 
labels  observe  that  it  way  arise  in  several  ways  and  has  the 
following  properties. 

1)  It  is  a  null  node  in  as  much  as  it  does  not  refer 
directly  to  any  data  i.e.,  its  name  is  not  that  of  a  UPIC  . 

2)  In  fig  3.6b  the  user  could  store  merely  a  single  copy  of 
a  UPIC  such  as  HAND  and  hence  save  core.  He  can  manipulate 
as  a  group  ARMS  (6  sub  pictures  appear  on  the  screen  or  M/F 
whereas  only  3  need  actually  be  stored  in  the  reference 
figure  which  resides  in  core)  or  LEFT  ARM  (3  sub  pictures) 
or  LEFT  (7  sub  pictures  -  all  those  on  the  left  side). 
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*LEGS 

HEAD 

*LEFT 

* RIGHT 

*LE  FT 

*RIGHT 

BICEP 

BICEP 

THIGH 

THIGH 

WRIST 

WRIST 

CALF 

CALF 

HAND 

HAND 

FOOT 

FOOT 

TOE 

TOE 

* 

indicates  a  "label" 

node  (see  page 

36) 

FIG.  3.6a 


FIG.  3.6b 
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The  hinge  pointer  is  omitted  here  for  clarity 


FIG.  3.7a 


FIG.  3.7b 
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This  is  only  relevent  when  angle  tables  are  used  as  will  be 
explained  later.  Normally,  one  needs  only  one  copy  for 
HAND  if  two  copies  are  seen  on  the  screen  -  the  angle  table 
approach  uses  one  array  to  store  the  flesh  outline  and  two 
sets  of  angle  values  to  position  it  for  each  of  the  two 
screen  positions. 

3)  The  user  may  elect  to  insert  labels  at  the  start  as  an 
aid  to  referring  to  UPIC  clusters  (one  command  for  A  HRS 
being  more  efficient  than  one  tor  each  of  LARM  and  RARM) . 

4)  If  the  user  appends  a  SPIC  to  an  existing  SPIC,  the  name 
of  the  appended  SPIC  becomes  a  label  in  the  newly  created 
concatenation  of  the  two  original  SPICS. 

Next,  observe  that  UPIC  names  are  to  be  comprised  of  two 
components:  A .  B  where  B  is  the  sub-picture  name  (eg  LEG)  and  A 

is  a  SPIC  name  which  uses  it  (eg  RANI).  For  example:  RANI. LEG, 
Thus  we  have  two  possibilities: 

1)  there  exist  two  SPICS, MANl  and  MAN2,  which  use  two 
different  subpictures: 

KAN  1 . LEG  and  MAN2.LEG ; 

2)  there  exist  two  SPICS, MAN1  and  MAN2  using  the  same 

UPIC, MAN  1 , FCOT  (if  FOOT  was  first  created  for  MAN1  and 
MAN2. FOOT  if  FOOT  was  first  created  for  MAN 2  and  then  later 
used  by  MAN1  or  MAN3  etc,). 

This  allows  us  to  use  the  ”B"  component  of  a  name  in  an 
angle  table  and  hence  one  table  can  be  used  to  impart  its  motion 
to  any  similarly  structured  picture  provided  it  uses  sub- 
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pictures  with  the  same  "B"  components  to  its  names.  We  could, 
of  course,  envisage  a  system  which  compared  the  tree  structures 
for  similarity  before  mapping  the  motion  of  one  SPIC  onto 
another  SPIC.  This  is  something  which  could  be  done  at  a  later 
stage  but  which  unduly  complicates  the  first  draft  of  such  a 
system. 

If  the  user  merely  refers  to  a  UPIC  which  is  in  core  as  xxx 
(instead  of  yyy.xxx)  then  the  system  will  assume  that  yyy  is  the 
SPIC  name  last  dealt  with  if  he  is  specifically  modifying  a 
SPIC.  Otherwise  it  will  simply  ask  him  to  input  the  missing 
SPIC  name  required  to  locate  the  UPIC. 

Having  described  the  data  organization  of  the  pictures,  let 
me  now  compare  the  ideal  requirements  of  page  32  with  this 
particular  scheme  point  by  point: 

1)  The  creation  of  UPICS  is  quite  straightforward  as  is 
modification  and  deletion.  The  danger  exists  in  the  scheme 
of  figure  3.1  that  the  user  might  create  a  chain  of  errors 
by  altering  or  deleting  a  UPIC  or  SPIC  which  is  used  by 
some  other  data  element  such  as  a  SEQUENCE.  In  order  to 
prevent  this  sort  of  error,  the  system  has  a  counter  built 
into  the  index  of  any  data  element  which  may  be  crucial  to 
some  other  entity.  This  counter  keeps  track  of  the  number 
of  pointers  to  a  particular  element.  For  example,  if  three 
sequences  all  use  SPIC=MAN  then  the  counter  is  set  to  3. 
Not  unless  this  counter  decrements  to  0  (no  dependencies) 
can  the  user  erase  MAN  from  the  library.  In  effect  this  is 
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a  DON'T 

MODIFY 

condition 

when 

COUNTER 

>  0 

and  MODIFY 

ALLOWED 

when 

COUNTER-0. 

To  most  users. 

most 

of  the  time. 

any  cha 

nge  in 

a  data  item 

which 

exists  in 

the 

library  or 

which  exists  in  the  core  and  is  already  being  utilized  by 
another  data  item  (COUNTER>0)  means  that  a  new  item  must  be 
created.  This  is  simply  done  by  a  COPY  operation  preceding 
the  modification.  When  space  is  scarce,  the  user  can 
delete  data  items  for  which  COUNTER=0.  When  space  is 
scarce  and  doubt  exists  as  to  the  wisdom  of  disk  deletion, 
items  can  be  put  on  tape  for  storage. 

2)  One  can  conceive  many  ways  to  allow  dynamic  changes  of 
the  flesh  and  hinge  areas  of  a  UPIC  in  core,  but  for  the 
most  part  these  will  involve  fairly  elaborate  software 
i.e.,  complex  pointer  chains.  The  method  chosen  (pg33)  has 
two  drawbacks,  neither  of  which  is  severe: 

-  it  is  time  consuming  since  garbage  collection 
operations  are  involved  from  time  to  time  as  opposed 
to  mere  pointer  settings 

-  the  user  is  asked  to  guess  at  the  number  of  data 
points  he  is  going  to  need  and  this  takes  user  time 
(i.e.  elapsed  computer  system  time). 

The  method,  however,  is  very  much  simpler  to  implement  and 
reguires  no  elaborate  memory  management.  In  fact,  if  core 
does  run  out,  a  program  can  be  written  which  lakes  more 
core  available  in  several  ways: 

-  free  core  used  by  arrays  the  user  indicates  he  no 
longer  wants; 
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-  trim  the  unused  portions  of  arrays  and  compress  them 
to  obtain  a  contiguous  area  of  free  core. 

3)  The  desire  to  create  a  SPIC  from  existing  UPICS  and  SPICS 
has  been  fulfilled  as  the  above  exposition  on  SPICS  and 
OPICS  has  shown. 

4)  &s  indicated  on  page  33  this  structure  makes  the  addition 
of  hinges  in  excess  of  the  number  originally  estimated  a 
little  slow  in  terms  of  execution  time  and  also  it  requires 
a  work  area  for  the  copy  operation.  However,  this  is  an 
unusual  event  and  for  the  majority  of  cases  we  can  safely 
say  that  the  operation  of  joining  two  pictures  at  a  hinge 
point  is  simple  to  perform.  The  scheme  is  simple  because 
it  uses  very  few  pointers.  The  drawback  of  greatest 
concern  is  that  as  a  consequence  one  cannot  readily 


determine  (by 

bac  k 

chaining)  hov  many 

hinges  attach  to  a 

given  hinge  and 

,  of  g 

reater  consequence. 

one 

cannot 

as  a 

result  delete  a 

hinge 

whithout : 

1)  leaving 

the 

row  location  of 

all 

other 

hinges 

unchanged ; 

2)  examining  the  entire  SPIC  array  of  every  SPIC  which 
uses  the  UPIC  whose  hinge  is  to  deleted  to  ensure  that 
no  other  node  of  any  of  these  SPICS  uses  this  hinge  as 
an  attachmenet  point  (if  this  isn't  ensured,  an 
element  of  a  SPIC  might  suddenly  become  attached  to  a 
most  unlikely  place  in  the  output  picture!) .  The 
solution  chosen  is  to  either  ask  the  user  to  seldom 
perform  this  tedious  operation  or,  as  a  more  immediate 
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and  utterly  simple  solution  to  implement,  never  allow 
him  tc  delete  a  hinge.  Finally,  as  far  as  moving  the 
hinge  is  concerned,  (which  amounts  to  deleting  and 
replacing  it  by  a  new  point  close  to  the  old)  no 
problem  arises  for  the  system. 

5)  To  avoid  undue  complexity,  I  have  chosen  to  ignore  all 
possible  types  of  line  thickness  and  intensity  except  for 
beam  OK  and  beam  OFF.  Since  the  intensity  parameter  is 
stored  in  a  halfword,  ample  space  exists  for  later 
elaboration  of  the  guality  of  the  drawn  line. 

6)  One  of  the  disadvantages  of  having  a  particular  UPIC  used 
by  several  SPICS  is  mentioned  in  (4)  above.  Another  is 
that  one  cannot  alter  a  library  copy  of  UPIC  unless  the 
change  is  going  to  leave  all  its  dependent  SPICS  unharmed. 
However,  the  great  advantage  is  that  a  great  many 
structures  may  be  created  item  a  limited  number  of  UPICS 

t 

and  hence  there  is  a  very  considerable  saving  of  coie  and 
raany  SPICS  can  often  be  modified  by  changing  only  the  small 
set  of  UPICS  from  which  they  are  constructed. 

Figure  3.8  shows  the  tree  structure  of  a  typical  SPIC  which 
represents  a  man  with  16  sub  pictures  each  of  which  has  a 
separate  UPIC.  The  SPIC  array  which  would  depict  this  structure 
is  shown  in  figure  3.9.  The  name  of  the  SPIC  is  MAN  and  in  this 
example  the  four  UPICS  L FOOT ,  RFCCT ,  LTOE,  BTOE  come  from 
another  SPICiMANB.  Column  4  is  left  empty  because  it  would 
contain  the  row  numbers  (in  their  appropriate  UPIC  arrays)  which 
designates  the  hinge  in  the  father  to  which  this  particular  UPIC 
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lr_Seau  en  ces_un  d_Sec|ue  nce_Tab  les 

Having  created  pictures  (SPIC  ol  UPIC)  the  user’s  next  move 
will  normally  be  the  creation  of  sequences  since  these  data 
entities  lie  i mmedia tely  above  pictures  in  the  data  structure 
hierarchy  and  are  created  by  reference  to  the  picture  libraries 
(see  fig. 3.1:  C,IC,IJ).  A  discussion  of  sequence  useage  was 
given  starting  on  page  22.  The  following  discussion  shows  how 
sequences  are  to  be  stored  in  the  system  and  gives  structural 
details. 

Suppose  the  system  is  to  retrieve  a  sequence  SE£X.  First 
the  sequence  index  (IC  in  fig. 3.1)  is  searched  for  entry  SE£X. 
This  yields: 

1)  the  number  of  other  sequences  or  activities  dependent 

upon  this  sequence; 

2) .  the  row  address  of  SE£X  in  the  sequence  table. 

The  row  (and  possibly  some  continuation  rows)  in  the 
sequence  table  is  read  into  core.  This  avoids  having  the  entire 
sequence  table  in  core  at  once.  The  data  in  this  row  is  used  to 
construct  the  sequence.  A  sequence,  once  constructed,  is  a  set 
of  pictures  and  can  be  manipulated  and  operated  upon  just  like 
any  other  SPIC  or  UPIC.  A  sequence  and  a  set  of  pictures  differ 
fundamentally  in  this  regard:  the  sequence  need  only  be  a  set  of 
’’potential-pictures”  defined  by  its  entry  in  the  sequence 


tables. 


SEQUENCE  TABLE 
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When  this  sequence  table  data  is  in  core  the  system  will 
face  several  possibilities  corresponding  to  the  type  cf  sequence 
that  SEQX  is.  Basically,  we  can  speak:  of  primary  and  secondary 
sequences  where  a  secondary  sequence  is  constructed  from  a 
primary  sequence  (more  of  this  later).  Therefore  the  first 
thing  to  discuss  is  the  creation  of  primary  sequences.  A 
primary  sequence,  PSEQX  say,  might  to  realized  as  a  set  of 
pictures  which  when  displayed  in  succession  form  a  short  and 
perhaps  cyclicly  repeatable  motion  sequence  in  one  of  the 
following  ways: 

1)  by  reference  to  the  sequence  frame  set  index  (SEQFS  INDEX 
IJ  of  fig. 3.1)  which  provides  pointers  to  a  set  of 
completed  pictures; 

2)  by  references  to  a  structured  picture  and  an  angle  table 
from  which  the  pictures  constituting  the  sequence  are 
constructed . 

Approach  (1)  involves  library  searches  only,  whereas  (2) 
requires  calculation  of  the  sequence's  frames.  An  explanation 
of  the  construction  and  use  of  angle  tables  is  in  order. 


£_Al]3.1e_Ta  t  les 

The  layout  of  an  angle  table  in  the  angle  table  library  is 
given  in  figure  3.11.  Given  a  motion  sequence  constructed  from 
a  structured  picture  it  is  possible  to  store  the  angles  of  the 
elements  in  the  picture  for  each  frame  of  the  sequence  and  the 
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SEGMENT  NAMES (UPICS)  ANGULAR  POSITIONS  STATE 


The  four  words  in  the  first  column: 

XAXIS,  YAXIS,  ROTATE,  SCALE 

are  reserved  words  which  tell  the  system  to 
apply  translations,  rotations  and  scale  factors 
to  the  entire  SPIC. 


THE  LAYOUT  OF  AN  ANGLE  TABLE 


FIG.  3.11 


45 


changes  in  overall  size,  position  and  attitude  froia  frame  to 
frame  in  an  angle  table.  This  table  serves  two  basic  functions: 

1)  core  and  library  space  saving; 

2)  mapping  of  motion  from  one  structure  to  any  related 

structure . 

In  figure  3.11,  column  1  contains  the  sub-picture  names, 
column  I  (1<I<N,  where  N=#  of  columns)  contains  a  list  of  the 
angles  or  positions  to  be  assumed  by  the  skeletons  of  the  sub¬ 
pictures  in  column  1  for  the  (I-I)st  frame  of  the  sequence. 

Thus  position  (i,j)  in  the  table  (ith  row,  jth  column) 
gives  us  (iff  j > 1 )  the  angular  displacement,  theta,  of  the 
skeleton  of  the  sub-picture  given  by  posit  ion  (i,  1)  relative  to 
its  rest  (or  normal)  position  for  the  (j~1)  st  frame  of  the 
sequence.  Actually,  it  refers  to  the  (j-l)st  key-frame 
(corresponding  to  the  "key-frame”  of  the  animators  terminology) 
since  there  may  well  be  interpolation  between  the  frames 
calculated  from  the  table.  The  interpolation  is  quicker  if  we 
do  a  standard  interpolation  between  completed  pictures  from  the 
table  than  if  we  interpolate  between  columns  of  table  values  and 
calculate  the  intermediate  picture  from  this  new  intermediate  or 
interpolated  angle  table. 

Note  that  an  angle  table 

(a)  may  be  altered  to  produce  changes  in  the  kind  or  quality  of 
motion ; 

(b)  may  be  referred  to  by  different  sequences  built  upon 


(i)  the  same  SPIC 
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(ii)  different  £ PICS. 

Point  b  (ii)  should  be  clarified.  Not  only  can  one  use 
SPICS  which  differ  in  terms  of  flesh  only  (i.e. ,  their  tree 
structures  are  invariant)  but  one  can  also  use  SPICS  which  have 
minor  variations  in  the  tree  structure.  The  worst  that  can 
happen  is  that  some  sub-pictures  which  don’t  appear  in  the 
table’s  first  column  will  remain  in  cne  position  all  the  time  or 
else  move  rigidly  (see  “locked”  and  "free"  hinges  below). 

The  last  column  of  the  table  contains  a  flag  (cr  mask  if 
one  wishes  to  distinguish  between  different  columns)  to  indicate 
whether  or  not  a  given  sub-picture’s  hinges  (attachment  hinges) 
are  to  be  "locked"  or  "free"  upon  rotation  -  definitions  of 
locked  and  free  hinges  follow.  If  "free",  all  limbs  attached  to 
the  limb  designated  "free"  will  suffer  no  rotation  when  the 
designated  limb  rotates.  If  "locked",  all  the  appended  limbs 
will  rotate  about  the  same  pivot  as  the  designated  limb  and 
through  the  same  angle  (see  fig. 3.  12). 

Finally,  if  the  first  column  contains  one  of  the  code  names 
corresponding  to  Dtheta,  Dx ,  Dy  or  S  then  the  columns  I  (1<I<N) 
for  such  a  row  designate  changes  in  angular  position,  in  the  x 
and  y  coordinates  and  the  scale  factor  respectively  of  the 
entire  structure  from  frame  to  frame.  Thus  a  bouncing  ball 
would  be  controlled  by  an  angle  table  with  cne  or  twe  rows:  cne 
for  Dy  and  (possibly)  one  for  Dx.  If  one  more  row  for  the  scale 
factor  is  introduced,  we  can  simulate  a  component  of  motion  in 
the  third  dimension  (perpendicular  to  the  plane  of  the  screen). 


(a)  LOCKED  (b)  FREE 

Here  B'  and  C'  are  locked  for  the  Here  B’  and  C'  are  free  and  hence  undergo 

rotation  from  B  and  C  and  hence  no  rotation  from  B  and  C. 

the  joints  are  rigid. 


(Since  A  has  been  explicitly  rotated  in  this  example,  it  does  not  matter  here 
whether  A  is  free  or  locked.) 


HINGE  STATES  ILLUSTRATED 


FIG.  3.12 
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Whether  or  not  there  is  a  row  for  Dtheta,  Dx,  Dy  or  S  is 
determined  by  a  reserved  word  in  column  1  of  the  angle  table 


which  tells  the  system 

that  the  entries 

for 

that  row  are 

changes 

in  one  of 
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S  to  be  applied 
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columns  I  and  1  from  row  1  to  the  last  row.  If  a  UPIC  name  is 
encountered  in  row  J,  then  the  entry  in  row  J  column  I  is 
treated  as  a  rotation  of  ANGT(I,J)  degrees  atcut  the  UPICS’s 
pivot  point.  If  row  J  contains  one  cf  the  four  reserved  words, 
then  when  all  all  the  non -reserved  words  have  been  used  in 
angular  computations  that  reserved  word  -  D t he ta , Dx , Dy , S-  will 
determine  whether  ANGT  (I,J)  is  to  be  a  change  of  attitude, 
displacement  or  scale  and  will  apply  this  change  to  the  entire 
SPIC.  In  the  case  of  Dtheta  the  assumption  has  been  made 
(experience  will  be  the  only  worthwhile  test  of  assumptions  of 
this  sort)  that  such  a  rotation  of  the  entire  SPIC  will  take 
place  about  the  principle  node's  pivot  point.  The  .principle 
node  of  a  SPIC  is  that  UPIC  which  acts  as  the  root  of  the  S PIC's 


tree  structure. 
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Seguence_Tjrjjes  (fig  3,10  pg  127} 

There  are  three  basic  categories  of  sequences:  Primary, 
Secondary,  Concatenated,  The  primary  sequence  is  one  which 
makes  direct  reference  to  the  picture  library  or  libraries 
either  through  index  IB  and/or  IA  directly  or  else  indirectly  by 
first  referencing  index  Id.  Secondary  sequences  are  created  by 
at  least  one  level  of  indirectness  since  they  refer  to  an 
already  existing  sequence  and  modify  it.  Concatenated  sequences 
are  simply  groupings  or  concatenations  of  up  to  five  sequence 
names  to  form  a  new  sequence.  This  concatenation  can  be  carried 
to  many  levels  of  indirectness  (although  it  will  clearly  be  time 
consuming  to  have  too  many  pointers  or  levels  to  trace  before 
the  UPIC.LIB  is  reached. 

ill  Unstructured  Primary  Sequence _ (U  FSj_ 

This  is  the  simplest  kind  and  examples  are  SA,SL  and  S M  in  fig 
3.10  following  page  43. 

(1-1)  In  SA,  the  most  common  sequence  to  the  average  anticipated 
user;  of  the  system,  two  entities  are  specified: 

SSE7-SA  which  is  the  name  of  the  set  of  unstructured  pictures 
residing  in  the  library  (note:  we  can  distinguish  frame  -  set 
names  from  SPIC  and  UPIC  names  since  the  former  appear  also  in 
the  frame  -  set  index  IJ  which  specified  the  number  cf  frames  - 
see  fig. 3. 1 )  and 

IF-SA  which  is  an  interpolation  factor  telling  the  system  that 
in  final  output,  IF-SA  frames  are  to  be  i nser ted  b  y 
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interpolation  between  each  pair  of  adjacent  frames  in  the 
library  of  frame-sets.  IF-SA=0,-1  implies  no  interpolation. 
IF-SA<-1  implies  the  system  selects  every  (TF-SA)th  frame: 

-1  select  them  all  (same  as  0) 

-2  select  every  2nd  frame 

-n  select  every  nth  frame. 

A  frame  set  SSET-SA  of  unstructured  pictures  is  comprised  of  a 
set  each  membeL  of  which  contains  only  one  UPIC  (there  is  no 
SPIC  to  sructure  the  frame).  The  members  may  be  treated  by: 

(1)  progressive  hand  drawn  changes  (lightpen  for  example) 
from  frame  to  frame; 

(2)  progressive  distortions  from  frame  to  frame  by  means  of 
functions  or  subroutines; 

(3)  transferring  each  sructured  picture  of  a  structured 
sequence  (see  (2)  below)  into  a  single  UPIC  which  will 
referenced  as  a  member  of  the  frame  set. 

i 

Members  created  under  (3)  may  be  further  modified  by  methods  (1) 
or  (2) f  and  clearly  each  of  (1)  and  (2)  can  modify  each  of  (2) 

and  ( 1)  . 

(1.2)  In  SL  we  have  an  unstructured  primary  sequence  (UPS) 
in  which  UPICX  and  UPICY  are  specified.  The  basic  intention  is 
to  allow  the  user  simply  to  specify  UPICX  and  UPICY  as  two  UPTCS 
which  transform  (X->Y)  by  means  of  j  intermediate 
interpolations.  Should  UPICY  also  appear  in  the  frame-set 
index,  then  UPICY  [1]  -  the  first  frame  cf  the  set  -  will  be 
used  as  the  picture  into  which  by  j  interpolations  UPICX  is 
transformed;  whereafter  the  remaining  frames,  UPICY[I]  (I>1), 
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will  be  appended  without  use  of  the  interpolation  factor-  See 
fig.  3.13. 

(1.3)  In_SM  we  have  the  uninteresting  possibility  that  the 
sequence  is  either  a  single  structured  or  unstructured  picture. 
This  case  is  redundant  since  direct  appeal  to  the  picture 
library  accompl ishes  the  same  result  for  an  activity.  However, 
more  than  one  means  should  be  provided  for  many  of  the  intended 
user  actions  in  order  to  provide  ease  and  flexibility  of  use. 
Hence  the  desirability  of  redundancy  of  interaction  procedures. 

J2f_S  tr  pc  t  ured_Pr  i-m  ary_Sequ  ences  q_SPS  X 

Here,  the  X  has  3  possible  interpretations  yielding  3  types 
of  structured  primary  sequences. 

SPSS;  structured  primary  sequence-simple  (frame  set) 

SPST:  structured  primary  sequence- 1 a  tie  created 
SPSB:  structured  primary  segue nce-both  SPSS  and  SPST 

(2.1)  SPSS  This  type  (see  fig  3.10:  sequence  SD)  is  similar 
to  the  UPS  exemplified  by  sequence  SA  and  differs  in  two 
particulars : 

(i)  the  frame-set  comprises  structured  pictures 

(ii)  it  may  refer  to  a  single  SPIC  from  which  the  set  was 
originally  constructed  (e.g.  MANHUN  might  be  a  frame-set  of 
SPICS  created  from  the  single  SPIC  known  to  the  system  as  HAN). 

(2.2)  SPST  (See  SC  in  fig.  3.  10).  This  type  is  what  is 
known  as  a  ’’potential”  seguence  since  it  does  not  necessarily 
exist  in  picture  form  but  can  be  created  when  desired  from  a 
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single  SPIC  (SPIC-C  in  fig  3.10),  a  table 
in  fig  3.10)  and  a  set  of  routines  which  mov 
of  the  SPIC  about  their  hinges  to  the  ang 
table  to  create  in  core  a  frame-set.  The  i 
is  used  (if  >  0)  to  interpolate  IF-SC  frame 
calculated  from  the  angle  table. 

(2.3)  SPSB..  This  is  simply  "BOTH"  of  SPST  a 
sequence  exists  as  a  frame-set  and  as  an  an 
It  is  not  intended  that  the  user  allow  hims 
confusing  himself  by  causing  the  two  cases 
structurally  quite  possible)  but  rather  th 
sequences  be  stored  permanently  (for  th 
creation  using  them  -  several  days  perhaps) 
recalculation  from  the  angle  table. 
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-UL_Secondary_Sequences_-_Siraple _ (SSS]_ 


This  type  of  sequence  (see  SF  in  fig  3.  10)  refers  to  some 
already  existing  primary  ,  concatenated  or  secondary  sequence. 
In  the  latter  two  cases  we  have  the  possibility  of  many  levels 
of  secondary  sequences  which  must  however  always  end  in  a 
primary  sequence.  Thus  a  secondary  sequence  (type  SSS)  adds  cne 
line  of  data  to  the  sequence  table  and  does  nothing  mere  to  cere 
reguirements  until  calculation  of  the  complete  frame  is  required 
for  output  to  screen  or  micro  -  film.  An  SSS  can  accomplish  two 
independent  tasks: 

1)  set  an  interpolation  factor  to  be  applied  to  the  frames 
of  the  sub-sequence  of  the  SSS; 
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2)  indicate  n°,  nf,  MC  (where  the  default  values  are 
1,M&X(n),  1  respectively)  where: 

NTC  =  #of  cycles  of  the  sub-sequence  that  are  to  be 
used  ; 

n  =  nth  frame  within  a  cycle; 

n°  =  number  of  the  frame  to  be  used  first; 

nf  =  #  of  the  frame  to  re  used  last; 

EAX  (n)  =  #  cf  f  rames  in  one  complete  cycle, 

(The  above  symbols  refer  to  the  frame  -  set  before  any 
interpolation  factor  has  been  applied,) 

J41_Concat  on  at  ed_Seq uences _ {CSX}. 

Should  a  user  wish  to  address  several  sequences  by  a  single 
name  he  may  do  so  by  concatenating  up  to  five  names  under  a  new 
name.  This  is  shown  in  fig  3.10  by  sequence  SE.  This  allows 
three  types  of  concatenated  sequences. 

null-  CSNq  concatenated  sequence  with  no  underlying  structural 
constant  (no  underlying  SPIC) .  In  other  words,  when  all  the 
sequences  have  been  expanded  or  traced  to  their  root  primary 
sequences  we  find  that  the  primary  sequences  are  all  cf  type  UPS 

-  unstructured. 

JJU21__  CSC:  concatenated  sequences  with  constant  underlying 
structured  picture.  In  other  words,  all  the  root  primary 
sequences  are  structured  and  they  all  have  the  same  SPIC  as 
their  basis.  Local  variations  (head) /(head  +  hat)  are  not 
significant,  the  concern  is  with  the  basic  tree  structure  and 
node  names  of  the  SPECS.  If  end  nodes  (hinds,  fingers,  tees. 


between  primary  sequences  this 


etc)  differ  from  SPIC  to  SPIC 
will  produce  miner  problems  or  no  problems  -  depending  upon  the 
operation  being  performed.  The  essential  point  is  that 
peculiar,  startling,  gross  or  puzzling  errors  will  not  result 
from  minor  differences  in  the  extremities  of  two  SPIC  tree 
structures.  This  is  by  far  the  most  powerful  sequence  type 
since  a  single  command  to  replace  for  example,  an  open  hand  with 
a  clenched  fist,  could  conceivably  affect  many  sequences  with 
closely  related  structure.  tfore  on  this  matter  later. 

(4.3) _ CSVp  Concatenated  Sequences  with  Variable  underlying 

structure.  This  is  simply  the  case  in  which: 

(a)  there  are  some  fundamentally  different  SPICS  underlying 
the  root  primary  sequences  or 

(b)  there  are  some  unstructured  sequences  (primary)  mixed  in 
with  the  structured  primary  sequences. 


true turai_Mgdifica tip ns_to_Segue nee s 

&  number  of  sequence  operations  can  be  defined  which 
produce  secondary  sequences  by  modifying  a  structured  sequence’s 
underlying  structural  groupings  in  some  way. 

(5.1)  Modify  the  underlying  SPIC  for  a  specific  number  of  frames 
(as  given  by  nO,  NC,  nf) . 

(5.2)  similar  to  5.1  but  certain  portions  of  a  SPIC  are  replaced 
by  another  sequence.  For  example,  suppose  the  basic  sequences 
at  our  disposal  are  KA N RUN  and  HEADTUHN  where  the  actions  are 
implicit  in  the  names.  We  might  wish  to  create  a  new  sequence 


MANSUNHEADTORN  by  replacing  the  HEAD  in  M  AN  RUN  *  s  SPIC  by  the 
entire  sequence  HEADTURN  for  a  user-designated  number  of  frames. 

Thus  we  is  us  t  now  consider: 

(a)  the  operations  desired  and  their  algorithmic  execution; 

(b)  the  specification  of  an  operation  in  the  sequence  table; 

(c)  the  manner  of  executing  the  operation  i.e.,  the  software 
which  will  execute  (a)  upon  (b)  to  give  a  new  sequence. 
Accordingly  sections  5.1  and  5.2  will  now  be  amplified: 

(5.1)  SSXP:  secondary  sequence  created  by  deleting,  adding  or 
replacing  portions  of  the  SPIC  underlying  a  sequence.  Hence  we 
have  SSDP,  SSAP,  SSRP  as  three  operations  on  structured 
sequences  to  produce  secondary  sequences  cr,  if  we  so  choose, 
new  primary  structured  sequences.  The  implication  of  the  last 
remark  deserves  some  special  attention:  a  digression. 

Upon  user  request,  the  software  should  be  designed  to 

i 

convert  any  secondary  sequence  (especially  of  the  type  currently 
being  discussed  -  namely  those  involving  structural  alteration) 
into  a  primary  sequence  referring  to  a  set  of  newly  created 


frames  in 

the 

libr ar 

y .  We 

co 

uld,  in 

a  highly 

so  phistica  ted 

system , 

ask 

that 

each 

use 

of  the 

reference 

to  a  secondary 

sequence 

be  counted. 

This 

cou 

nt  creatio 

n  could  prove  a  complex 

algorithm  since  we  might  want  to  throw  in  various  weighting 
factors:  time  reguired  to  create  sequence  upon  request  -  which 
might  be  a  function  of  size  or  linkage  complexity  -  ,  lifetime 
(predicted) ,  age  (from  date  of  creation)  and  so  forth  and  this 
count  could  -  upon  reaching  a  threshold  -  trigger  the  conversion 
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routine.  Here  the  decision  is  left  to  the  user’s  intuition  and 
discretion. 

(5.1a)  SSDP  Deletion  of  sub-pictures  to  create  a  new  sequence 
(fig.  3.10  sequence  SG) .  We  start  with  a  stLUctured  primary 
sequence  SEQ-SY  and  delete  a  sub-picture  or  group  of  sub- 
pictures  to  create  a  new  secondary  sequence.  If  the  user 
requests  permanent  storage  of  the  resultant  frame  -  set  then 
this  secondary  sequence  will  be  converted  to  a  primary  sequence. 

Some  definitions  are  useful  here.  In  the  tree  structure 
representing  a  SPIC  a  node  refers  tc  one  of  the  pictures  in  the 
structure  (a/b,  etc.,  in  fig.,  3.14(a)).  h  branch  refers  to  all 
the  descendants  of  a  node  and  the  node  itself  or  in  ether  words 
the  "branch”  of  a  picture  is  the  set  of  pictures  consisting  of 
the  picture  itself  and  all  those  pictures  which  are  attached  to 
it  (its  sons) . 

The  execution  of  an  SSDP  operation  is  as  follows: 

(i)  The  sub-sequence  (SEg-SY)  is  set  up  in  cere  (read  in 
from  library  or  else  created  in  core  from  a  SPIC  and  an 
angle  table) . 

(ii)  The  branch  (sub-picture  or  group  of  sub-pictures)  is 
deleted  from  each  frame  as  shown  in  fig.  3.14.  In  the 
diagram.  If  we  choose  to  eliminate  branch  f  then  all 
descendents  of  node  f  are  stricken  from  the  SPIC  and  the 
brothers  remain. 

(5.1b)  SSAPj.  Addition  of  sub-pictures  to  create  a  new  sequence 


(a)  ORIGINAL  SPIC  TREE  STRUCTURE 


a0 

y 


f> 


c 

-O- 


0  o 

«  h 


d 

-Q- 


-O 


Q - D 


(b)  DELETE  NODE  f 


FIG.  3.14 


0 


,  i  c  d  e 

b  5  — o- -  :"> - o 


iO — Oj 


go- 


_fi, h 


k° 


(a)  ORIGI NAL  SP I C  TREE  STRUCTURE 


(b)  ADDITION  OF  NODE  m  TO  NODE  d 


6 — 


o . — o 


0- 

i 

! 

O 


0 

I 

I 


o 

% 

I 


— o 


i 

b 


m 


ETC 


BRANCH  m:  o 


ETC 


* 

o 

i 

i 

s 


ETC 


(c)  ADDITION  OF  BRANCH  m  TO  NODE  d 


ETC 


FIG.  3.15 


56 


{fig  3.9  sequence  SH).  This  is  analogous  to  5.1a  above  (see  fig 
3.15).  Conceptually  very  simple,  like  ail  these  operations  it 
entails  the  creation  of  new  pointeLs  in  the  tree  structure  (at 
nodes  j  and  m  in  the  example)  and  will  involve  dynamic  core 
allocation  and  garbage  collection  to  produce  one  contiguous  STIC 
array . 


{5.  1c)  SSRP:.  Replacement  of  sub-pictures  by  nodes  or  tranches  of 
other  sub-pictures  (or  of  itself)  to  create  a  new  sequence.  See 
fig.  3. 16.  This  involves  the  most  elaborate  pointer 
realignment  of  the  three  cases  under  discussion.  The  diagram  is 
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in  fig. 3.10,  as  are  the  words  BRANCH,  NODE,  SEQ....  The  system 
will  provide  in  column  two  a  code  word  which  will  cause  the 
appropriate  interpretation  to  made  of  each  column's  contents  by 
the  software.  This  code  word  will  be  provided  by  reference  to 
the  user's  decisions  at  the  screen  interface. 

(5.2)  SSXSi  structured  secondary  sequence  created  by  the 
addition  or  insertion  of  a  sequence  to  some  portion  of  a  SPIC  in 
the  sub-sequence.  This  gives  SSAS  (addition)  and  SSBS 
(replacement)  as  the  last  operations  to  be  discussed  under 

sequences . 

(5.2a)  SS  RS q  essentially  this  command  expands  to  read  "replace 
branch  X  in  the  SPIC  of  the  sub-sequence  SEQ-SV  by  branch  Y 
(which  may  in  fact  be  the  entire  SPIC)  of  the  specified  sequence 
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SEQ-Y  and  do  so  over  a  frame  range  given  by  (nO,NC,nf)  or  else 
their  default  values  (which  are  obtained  from  the  sub-sequence 
SEQ-SV) .  See  SJ  in  figure  3.10  for  the  example  of  this  type  of 
sequence.  Lastly,  the  replacement  branch  must  have  its  hinge 
pointer  adjusted  so  that  -  as  in  fig  3.17  -  the  hinge  of  B*  can 
mate  with  its  pivot  point  in  A. 

(5.2b)  SS ASg_  which  is  a  command  to  ’'add  branch  ¥  of  SEQ-Y  to 
node  X  of  the  original  sequence  SEQ-SV”. 

Scenes  (E  and  G  in  fig  3.1) 

In  the  system  a  scene  name  points  to  two  tables: 
an  activity  table  (E) ; 
a  camera  instruction  table  (3). 

The  contents  of  these  tables  are  used  to 

(1)  place  sequences  on  the  animation  table 

-  starting  at  the  desired  size,  place,  angle; 

-  ending  at  the  desired  size,  place,  angle; 

-  following  the  desired  path  with  rates  of  change  in 
position,  angle  and  size  given  by  the  user; 

(2)  position  the  camera  for 

-  zooms, 

-  pans 

-  tracking 

-  masking  (masks  over  the  "lens”) 

-  simple  static  shots  or  "holds". 
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See  fig.  3.18  for  an  example  of  an  activity  table.  It  is 
48  bytes  wide  and  has  a  number  of  rows  determined  by  need  - 
usually  one  activity  per  row  although  an  activity  will  use  two 
rows  of  the  table  if  it  refers  to  a  control  curve.  For 
convenience  the  14  columns  have  been  labelled  at  the  top  of  the 
table  along  with  the  byte  width  of  each  column. 

A  general  explanation  of  an  activity  was  given  in  chapter  2 
as  a  set  of  parameters  defining  exactly  when,  where  and  hew  a 
sequence  is  to  be  plotted  upon  the  animation  table.  The 
parameters  stored  for  a  particular  activity  in  the  table  are 
these  (see  figure  3,  18) . 

Activity  name  by  which  the  user  designates  the  activity 
Cel_leyel_number  which  indicates  the  number  of  the  cel  on  which 
the  picture  is  to  be  placed  (cel  #  1  is  in  the  foreground) . 
This  concept  is  only  for  use  with  hidden  line  removal  algorithms 
and  hence,  since  they  are  not  employed  at  present  in  this 

i 

system,  will  not  be  used.  A  general  purpose  hidden  line  removal 
algorithm  for  figures  of  the  complexity  required  by  an  animator 
would  take  far  too  long  to  execute  -  hence  its  omission  here. 
If  we  were  to  use  a  raster  TV  type  display  tube  then  the  use  of 
area-filled  rather  than  outline-drawn  figures  would  enable  some 
fairly  simple  over lay  algorithms  tc  take  gcod  advantage  of  the 
cel  level  concept. 

Se£uence_name  which  refers  to  the  sequence  referenced  by  this 
activity.  Frames  from  a  sequence  will  be  used  cyclicly  by  an 
activity  if  the  motion  is  repetetive  (i.e.,  cyclic)  and  will 
freeze  or  remain  on  the  sequence's  last  frame  for  non— cyclic 
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sequence  motion. 

E0X  the  initial  position  of  the  first  frame  of  the  sequence 
comprised  of  its  (x,y)  position,  attitude  (theta)  and  size  or 
scale  factor.  The  parameters  are  given  in  terms  of  changes 
(i.e.,  Dx,  Dy,  Dtheta,  DS)  required  to  go  from  their  state  as 
read  from  the  sequence  library  to  that  required  for  EC  of  the 
activity . 

Ef  the  final  position  or  "envelope"  cf  the  sequence. 

the  frame  range:  f°  is  the  activity's  entry  frame  and 
ff  its  exit  frame  in  the  scene. 

In  other  words,  if  the  frames  of  a  sequence  whose  "center 
of  gravity"  is  at  rest  can  be  encompassed  by  a  minimum  enclosing 

rectangle  E,  then  this  rectangle  must.  te  mapped  by  four 

operations  (Dtheta,  Dx,  Dy,  Scale)  onto  some  rectangle  Ei 
required  by  the  activity.  The  Ei  will  be  determined  in  one  of 
several  ways: 

(1)  provide  E°,  Ef  and  n°,nf  and  specify  a  method  of 
interpolation  from  E°  to  Ef  (see  below)  ; 

(2)  provide  E°,  n°,nt  -  here  E°  =  E  f  unless  the  sequence 

contains  built  in  values  of  Dtheta, Dx,  Dy,  S  (see  pg.44) 

and  in  either  case  Ef  is  determined  by  the  other 

parameters ; 

(3)  provide  E°,  n°,  NC . 

If  the  interpolation  of  the  sequence's  appearance  in  EO  to 
its  appearance  in  Ef  over  (fo,ff)  is  to  be  linear,  then  the 
continuation  pointer  column  is  null.  Otherwise  it  references 
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that  row  in  the  activity  tafcle  containing  the  interpolation 
data .  In  connection  with  non-linear  interpolation  from  E0  to  Ef 
there  are  two  cases:  independent  and  interdependent 
transformations. 

Independent^ Kg n_lineaL_T La ns for mat ionsp 

(Linear  transformations  are  also  independent 
transformations.)  To  the  user  they  are  4  separable  operations. 
He  positions  an  envelope  at  E°,  then  moves  a  copy  of  this 
transforming  it  to  Ef  -  the  4  parameters  x,y,  scale,  theta  are 
handled  "independently**.  If  a  user  wishes  to  isolate  one  or 
sore  of  the  transformations  -  rotation,  scaling,  translation  - 
on  E0  to  Ef  in  order  to  produce  a  ncn-linear  interpolation  of 
that  parameter  (or  parameters  in  the  ease  of  translation)  he  may 
do  so  by  "independent”  operations  in  the  following  manner. 
Having  set  up  E0  and  Ef  lie  will  select  one  of  the  three  basic 
transformations: 

Potation  , 

Translation,  or 
Scaling 

and  draw  a  graph  (the  procedures  are  given  later  in  appendix  A 
-formats  16,17,18)  171  if)  showing  how  the  parameter  is  to  be 
interpolated  from  its  intial  value  implicit  in  EC  to  its  iinal 
value  implicit  in  Ef.  The  graph  is  known  as  a  "control  curve". 


Control  Curves 
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There  are  three  types  of  control  curve  or  CC: 

TCC  :  translation  control  curve 
HOC  :  rotation  control  curve 
SCC  :  scale  control  curve 

If  the  user  elects  to  either  create  a  new  control  curve  or 
else  call  upon  an  already  existing  control  curve  for  this 
purpose ,  column  13  (halfword)  contains  a  pointer  to  a 
continuation  row  in  the  activity  table.  A  con tinua tion  row  is 
distinguishable  from  the  initial  row  by  a  code  word  cr  special 
symbol  in  column  one.  In  this  continuation  row  is  stored  the 
following  data  (these  are  all  ± ull words) : 
column  7  ;  name  of  TCC,  if  any 
column  8  :  name  cf  KCC  it  any 
column  9  :  name  cf  SCC  if  any 
column  10  :  x  coordinate  of  point 

column  11  :  y  coordinate  ot  tie-down  point 

column  12  :  name  of  attitude  control  curve  (ACC)  to  be  used  as 
an  optional  method  for  the  control  of  the  tie-down  coordinate. 

An  example  of  a  TCC  is  given  in  tig  1.19  where  we  can  see 
that  the  shape  of  the  TCC  determines  the  path  of  the  envelope 
and  that  the  displacement  IT  between  the  points  constituting  it 
determines  the  DT  between  each  position  of  E  as  it  moves  from  E0 
to  Ef . 

The  three  independent  transformations  will  now  be  covered 
in  detail: 

1)  Translation 


(n)  is  the  maximum  number  of  bytes  needed  for  the  column.  Total  table  width  is  therefore  4  x  13  =  52  bytes 


CD  C'  D' 


FIG.  3.19 
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The  user,  in  format  16  (appendix  A)  indicates  to  the  system 
which  activity  he  is  about  to  work  with  and  then  either  calls 
upon  an  existing  control  curve  or  else  creates  a  new  control 
curve  and  names  it.  To  create  a  translation  control  curve  the 
user  sketches  it  with  a  light  pen  and  usually  he  will  make  it 
connect  some  point  P  on  EG  to  the  analogous  point  P  on  £f.  The 
point  density  will  be  inversely  proportional,  to  the  resulting 
velocity.  If  the  user  calls  upon  an  existing  TCC  to  move  E  from 
EO  to  Ef  then  the  x,  y  coordinates  of  Et  will  be  ignored  if  they 
exist  and  will  be  determined  by  the  TCC.  The  user  creates  a 
series  of  points  p1,  p2..„.pn  to  form  a  ICC.  However,  what  is 
stored  is  DP1=p2-p1,  EP 2-P3-P2 . . . . DPn~ 1 -P n- Pn- 1 ,  where  by 
DPi=Pi+l-Pi  is  meant  Dx  { i )  =  x(i+1)-x(i)  ,  Dy  (i)  =y  (i  +  1  )-y  (i)  ,  or 
the  n- 1  intervals  between  the  specified  points. 

2) 

t 

When  the  user  wishes,  while  working  with  a  particular 
activity  which  he  has  specified,  tc  cause  E  to  rotate  from  its 
angular  position  in  EO  to  that  in  If  he  goes  to  format  18 
(appendix  A)  where  he  is  presented  with  a  spiral  graph  (the 
number  of  revolutions  or  the  ’’tightness”  of  which  the  user 
specifies  by  changing  a  parameter  in  the  spiral’s  eguation)  and 
a  number  (a  default  number  or  else  user  specified)  of  radial 
lines  which  together  form  a  grid  upon  which  the  user  places  by 
light  pen  the  points  of  a  ’’rotation  control  curve”  or  CCC.  All 
that  the  system  actually  needs  store  are  the  angular  changes 
from  position  to  position:  D  theta  n  -  theta  11+1  -  theta  n.  Two 
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radial  lines  are  all  that  need  be  displayed,  one  to  indicate  the 
initial  position  theta  0  and  another  (distinguished  somehow, 
perhaps  by  double  thickness  (mtensi ty) )  to  indicate  the  terminal 
position  theta  f. 

3)  Scale 


tor  non  linear 

scale  changes  the 

u  s 

eL 

goes  to 

format 

17 

(appendix  A )  ana  i 

s  presented  with  a 

n 

- 1  p  h 

or  scale 

versus 

time 

or  which  are  placed 

the  values  S°  ana 

(i 

r  it 

e  x  i  s  t  s ) 

g  r 

>_«  i.  • 

1  he 

usoj.  sketches  in  a  curve  whose  height  represents  the  scale 
factor  and  whose  lateral  position  represents  time.  Here  SCC 
contains  the  values  of  the  scale  { actor  S. 

In  all  three  control  curves,  the  programs  utilizing  them 
will  need  to  provide  solutions  for  the  high  probability  that  the 
number  or  frame  changes  the  user  has  allowed  for  in  the  control 
c.urve  differs  (ana  not  necessarily  ty  an  integral  factor)  from 
the  number  of  frames  actually  called  for  by  the  activity  since 
we  don't  want  the  user  to  have  to  provide  exact  solutions  which 
would  mean  time  consuming  iteration  in  the  creation  cl  a  control 
curve.  In  short,  the  computer  is  best  left  to  compute  the  exact 
number  of  frames  from  the  hand  (light  pen)  drawn  first 
approximation  of  the  control  curve. 

Inter  -  dependent  Transfer  am  t ions _ (iCC_ a nd_ R  C Cf 

and  Tie  -  down  Points. 
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Suppose  {fig  3.20)  that  a  user  wishes  to  cause  an  envelope 
E  to  move  tangentially  to  a  TCC  -  e.g.,  a  car  in  silhouette 
climbing  over  the  crest  of  a  hill.  In  the  case  of  a  car  he 
would  ask  the  system  to  display  the  position  E0  at  the  starting 
position  so  that  the  wheels  lay  in  tangential  contact  with  the 
TCC,  with  the  rear  wheel  at  the  start  of  the  TCC.  Note  that  in 
this  example  the  wheels  do  not  turn  -  this  is  for  simplicity  of 
exposition  and  is  not  difficult  to  do.  At  this  stage,  the  user 
selects  a  "tie-dcwn"  point  -  namely  the  front  wheel  of  the  car 
at  the  point  that  it  is  to  make  contact  with  the  road  (TCC 
here) .  The  system  software  will  use  this  point  to  rotate  E 
about  the  current  point  in  the  TCC  so  that  the  tie-down  point, 
TD,  remains  on  (or  in  practice  very  close  to)  the  TCC.  Thus  the 
function  of  the  HCC  is  implicit  in  this  use  of  the  TCC  plus  the 
TD  point  hence  the  term  Mi nterdependent”  control  curve. 

AhQQl  Attitude _ Control _ Curve..  In  column  7  is  stored  the 

optional  ACC  (Attitude  Control  Curve)  which  can  be  used  to 
control  the  location  of  the  TD  point  independently  of  the 
original  TCC.  This  ACC  is  used  to  control  the  "attitude”  or 
angle  of  the  envelope  as  it  moves  along  the  TCC.  An  example  is 
shown  in  fig  3.20. 

There  are  three  control  curve  (CC)  libraries  (CCLIB) : 

1.  TCCLIB  (includes  TCC's  and  ACC’s); 

2.  HCCLIB ; 


3. 


SCCLIB. 


FIG.  3.20  (b) :  ACC  CURVE  USAGE  IN  WHICH  TD  POINT  IS  TIED  TO  A  SECOND 

C.C. :  THE  ACC 


FIG.  3.20  (a):  TD  POINT  USAGE  IN  WHICH  THE  ONE  TCC  IS  USED  FOR  BOTH 

TCC  AND  ACC  PURPOSES 


FIG.  3.20 
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These 

are  shown 

in 

table  3.21 

and  are 

stra ight f orwa 

rd . 

TCC*s  are 

stored  in 

the 

same  form  as 

UPIC’S  so 

that  they 

ma  y 

be 

operated  u 

pon  by  all 

the 

t ra nsf orma  ti 

ons  applica 

fc 1 e  to  a 

UP 

IC. 

This  is  also  necessary  since  many  TCC  curves  might  he  an 
integral  part  of  the  picture  itself. 

Camera  Instruction  Tables 


This  table  (see  figure  3.22)  is  almost  identical  in 
structure  to  the  Activity  Table  of  figure  3.18.  It  differs  in 
the  following  manner: 

1)  Column  2  is  not  critical  and  will  only  be  used  if  the 
user  wishes  the  caraera’s  viewfinder  to  be  exactly  filled  by  the 
activity  referred  to  by  name  in  this  column  i.e.,  if  we  wish  to 
track  this  activity  exactly.  In  this  case  the  remaining  columns 
will  be  filled  by  the  system  by  reference  to  the  activity  table. 
The  reason  for  retaining  the  reference  to  the  activity  even 
after  its  instructions  are  copied  into  the  camera  table  is 
simply  to  cover  the  possibility  of  later  modifications  to  the 
activity  -  hence  the  need  for  a  last  minute  update  of  any 
references  to  an  activity  in  column  two.  In  either  case  (column 
2  empty  or  used)  the  table’s  entries  are  used  to  create  •’empty” 
( no  seg uence  referenced)  activities  which  correspond  to  the 
rectangular  area  seen  by  the  camera  lens.  If  this  window  is 
made  to  rotate  45°  clockwise  and  move  left  to  right,  top  to 
bottom  simultaneously  while  also  expanding  to  twice  its  normal 
size  (fig  3.23)  as  it  moves  across  the  "table”  then  the  scene  in 
the  output  film  will  simply  do  the  exact  opposite. 

2)  There  is  the  possibility  of  inserting  a  "mask"  over  the 
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SIZE (n)  =  SIZE (0)  x  SCALE (n) 
theta(n)  =  theta(n-l)  +  Dtheta(n) 


FIG.  3.21 
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lens  (any  portion  of  the  mask  outside  the  envelope  is  of  course 
wasted  or  unused)  and  this  is  simply  any  closed  curve  (  a  UPIC) 
-  the  name  of  which  is  stored  in  the  continuation  row  at  column 
6  -  which  can  act  as  a  window.  See  figure  3.24. 

3)  All  the  frame  ranges  must  be 

(i)  non-overlapping 

(ii)  perfectly  contiguous 

or  else  we  will  have  (i)  multiple  camera  instructions  for  the 
same  frame  or  (ii)  no  commands  for  some  frame  (s)  .  The  fortaer 
possibility,  (i) ,  must  be  completely  disallowed.  If  the  user 
creates  non-con t igucus  frame  ranges  there  will  be  two  rows  left 
vacant  and  flagged  between  all  pairs  of  instructions  in  which 
FN°  (I) *FNf  (I- 1 )  +  1  is  true.  If  the  user  attempts  to  go  to 
final  output  when  such  flagged  rows  exist,  he  will  be  warned. 
If  he  chooses  to  override  the  warning  rather  than  explicitly 
create  the  missing  instructions  then  linear  interpolation 
activities  will  be  generated  to  fill  in  from  Ef  (Cli)  to 
E°(CIi+l)  where  i  is  the  ith  camera  instruction. 

The  instructions  are  ordered  by  frame  range  to  reduce 
search  times  at  output.  Similarly,  the  activities  of  section  E 
are  ordered  by  FN°. 


Fi lm_Tables 

See  figure  3.25  for  the  layout  of  these  tables.  If  a  user 
selects  a  film  MFX”  then  he  is  directed  to  an  array  (film  table) 
FX  which  simply  contains  an  ordered  list  of  scenes  and  two 
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pointers : 

i 

» 

1)  a 

pointer 

to 

the 

activity  table  of 

the  scene 

2)  a 

pointer 

to 

the 

camera  instruction 

table  of  the  scene. 

Indexes 

A  glance  at  figure  3.1  shows  the  various  indexes  required 
to  support  these  tables.  Before  going  on  to  chapter  *4,  I  should 
make  the  following  programming  comment  since  it  affects  the 
detailed  structure  of  all  the  tables.  It  is  essential  to  have  a 
column  (an  integer  halfword  will  suffice  unless  the  system  is 
used  extraordinarily  heavily  and  driven  by  user  routines)  which 
stores  a  count  of  the  current  number  of  references  to  the 
particular  row  of  data.  If  this  is  not  done,  someone  might 
delete  a  scene  from  his  movie  and  also  from  the  scene  library, 
unaware  that  he  has  destroyed  another  film  which  also  used  the 
same  scene.  Even  more  likely  is  the  possibility  of  deletions  in 
UPIC  LIB,  one  of  the  CC  LIB  's,or  SP IC  LIB  when  the  user 
deletes: 

-  a  UPIC 

-  a  SPIC 

-  a  SEQ 

/ 

-  a  MASK 

-  a  control  curve. 

If  these  deletions  are  done  without  a  knowledge  of  the  state  of 
cross  -  references,  disaster  could  occur.  The  untimely  removal 
of  a  single  SPIC  could  conceivably  eliminate  half  the  supporting 
picture  data  for  an  entire  movie! 


Therefore  any  consideration 
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of  core  requirements  will  expand  by  one  halfword  the  width  of 
the  following  arrays: 

1)  Angle  Table  Index 

2)  Control  Curve  Index 

3)  Picture  Indexes 

4)  Frame  -  Set  Indexes  (which  in  turn  refer  to  one  of  (3)). 

5)  Scene  Index 

6)  Film  Index. 

In  these  arrays  what  is  needed  is  a  fullword  of  data  (a  set  of 
codes  to  be  more  explicit)  to  inform  a  user  as  to  whether: 

(a)  the  film  is  completed  (when) 

(b)  the  film  exists  on  tape  (which  one) 

(c)  the  film  exists  on  film  (and  how  many  copies) 
and  (d)  how  long  the  film  runs 

(e)  how  much  computer  time  its  output  (final)  took 

(f)  how  much  computer  time  was  used  in  its  overall  creation. 

i 

I  do  not  think  we  are  yet  at  the  stage  where  more  elaborate 
data  accounting  is  needed  and  hence  will  make  no  attempt  to 
guard  against  unwanted  user's  tampering  with  data  sets.  Thus 
there  need  be  no  user  code  words  to  govern  who  may  read  and 
write  data  or  execute  programs.  Such  safeguards  are  only 
necessary  in  a  commercially  successful  computer  animation 
system . 
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CHAPTER  4 


PERFORMANCE  ESTIMATES 


By 

means  of 

a  pencil  and 

paper 

sirnu 

lation  o 

involvin 
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creation  of  a 

one 

minute 

movie  se 

chapter 

endeavou 

rs  to  provide  a 

performance 

estimate 

of  how  the  system  will  be  used.  The  path  from  t 
crude,  intuitive  idea  for  a  movie  to  the  finished  pro 
constituted  in  many  ways.  The  specific  creation  p 
this  scenario  was  chosen  because  it  is  logically  ve 
The  creation  stages  could  be  as  follows. 

(a)  Initial  work  sheet  (fig  4.1)  on  which  is  desc 
breakdown  of  the  scene's  action  (i.e.,  one  wor 
scene) .  The  user  here  indicates  the  approximate 
duration  desired  for  each  separable  action  in  th 
the  nature  and  duration  of  the  camera  movements 
mind  his  ultimate  goal  of  creating  seguenc 
possible  in  order  to  reduce  the  number  of  frames 

(b)  From  the  work  sheet  the  user  can  now  prepare 
4.2b,  4.2c)  a  table  of 

(1)  all  the  pictures  (subdivided  for  conven 

SPIC  and  UPIC)  needed, 

(2)  all  the  sequences  he  thinks  he  will  nee 

(3)  and  from  (2)  he  estimates  the  set  of 

which  will  likely  do  the  job  and  finally 

(4)  he  prepares  a  list  of  the  camera  instru 
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DESCRIPTION  OF  THE  ACTION  IN  THE  ACTIVITY 
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(a) 

UPICS  REQUIRED 

NAME 

OF  POINTS 

1 

Title  of  Film 

TITLE 

200 

2 

End  of  Film 

END 

40 

3 

Credits  for  Film 

CREDIT 

60 

4 

Street  Scene 

STREET 

500 

5 

Sun  plus  Clouds 

SKY 

200 

6 

Tree  Scene 

TREES 

1000 

TOTAL 

NUMBER 

OF  POINTS 

2000 

(b) 

SPICS  REQUIRED 

NAME 

POINTS 

1 

Big  Man 

BMAN 

200 

2 

Little  Man 

LMAN 

200 

3 

Woman 

WMAN 

200 

4 

Chaos 

CHAOS 

1400 

TOTAL 

NUMBER 

OF  POINTS 

2000 

(c) 

SEQS  REQUIRED 

NAME 

FRAMES 

POINTS 

1 

Title  Dissolves  to  UPICS 

SKYSEQ 

2 

BMAN  Walking  Left 

to  Right 

BMWLK 

20 

5000 

(*250) 

3 

WMAN  "  " 

"  "  with  BMAN 

BWWLK 

20 

8000 

(*400) 

4 

M  M  II 

"  "  "  LMAN 

LWWLK 

20 

8000 

(*400) 

5 

BMAN  Running  Away  from  Viewer 

BMRUN 

10 

2500 

(*250) 

6 

BMAN  Tipping  Hat 

and  Stopping 

H ATT IP 

24 

6000 

(*250) 

7 

BMAN  and  WMAN  Walk  off  Together 

PICKUP 

24 

12000 

(*500) 

8 

WMAN  Plugs  in  the 

Cord 

PLUGIN 

24 

6000 

(*250) 

9 

BWWALK  comes  to  stop  and  WMAN  splits 

WSTOP 

12 

6000 

(*500) 

10 

Street  Scene  Fades  into  Existence 

FADE IN 

2 

6000 

(*500) 

TOTAL  NUMBER  OF  POINTS 

53500 

STRUCTURE  ESTIMATES  FOR  SCENARIO 


FIG.  4.2  (a,b,c) 


#  OF  ACT 


TIME 


ACTIVITIES  NEEDED 


NAME 


1 

0. 

- 

4. 

Display  title  at  centre  of  table 

DTLE 

2 

4. 

- 

6. 

Fade  in  street  scene  under  title 

DFDE 

3 

6 . 

- 

8. 

Dissolve  title 

DSLV 

4 

8. 

- 

15. 

BMAN  walks  in  from  the  left  onto  ACT*  #2 

BWLK 

5 

13. 

- 

17. 

WMAN  standing 

WSTD 

6 

15. 

- 

17. 

BMAN  stops,  raises  hat 

RHAT 

7 

17. 

- 

19. 

Couple  turns  and  walks  off  together 

TURN 

8 

19. 

- 

25. 

Couple  walking 

CWLK 

9 

23. 

- 

29. 

LMAN  standing 

LSTD 

10 

25. 

— 

29. 

Couple  stops,  WMAN  bends  over  and  plugs 
in  the  cord 

PLUG 

11 

29. 

- 

31. 

LMAN  pushes  up  hat  and  smiles 

SMIL 

12 

31. 

— 

40. 

LMAN  dissolves  into  CHAOS  along  with 
street 

CRMB 

13 

40. 

** 

44. 

LMAN  and  WMAN  emerge  from  chaos  going  to 
right 

EMRG 

14 

40. 

- 

42. 

BMAN  emerges ,  running  away 

BMRG 

15 

44. 

- 

50. 

Couple  walks  off 

LWLK 

16 

50. 

- 

53. 

Display  "end" 

END 

17 

53. 

- 

55. 

Display  credits 

CRDT 

STRUCTURE  ESTIMATES  FOR  SCENARIO 


FIG.  4.2  (d) 


#  OF 

C.I. 


TIME 


CAMERA  INSTRUCTIONS 


NAME 


1 

1. 

-  8. 

Hold  steady  for  titles  etc. 

HLD1 

2 

8. 

-  11. 

Zoom  in  on  man 

ZM1 

3 

11. 

-  14. 

Track  man's  motion 

TRK1 

4 

14. 

-  19. 

Steady 

HLD2 

5 

19. 

-  24. 

Track  couple's  motion 

TRK2 

6 

24. 

-  44. 

Steady 

HLD2 

7 

44. 

-  46. 

Track  couple's  motion 

TRK3 

8 

46. 

-  50. 

Zoom  out 

ZM2 

9 

50. 

-  55. 

Hold  for  "end"  and  credits 

HLD3 

POSSIBLE  NAMES  FOR  THE  CAMERA  INSTRUCTIONS  of  4.1 


FIG.  4.2  (e) 
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<C) 

He 

no 

w  draws  the  pictures  need 

ed 

in 

one 

of 

several  ways 

(d< 

ape 

ndi 

ng  upon  hardware) : 

(1) 

code  the 

picture  off-lin 

e 

for 

bate 

h 

input ; 

(2) 

digitize 

the  picture  on 

or 

off 

lin 

e; 

(3) 

input  it 

interactively  v 

ia 

a  d 

ispl 

ay 

device  (scope 

and 

light  pe 

n)  . 

W 

At 

th 

is  point 

he  has  a  picture 

1 

ibra 

ry  a 

nd 

can  start 

work 

on 

scenes 

and  sequences. 

A 

num 

ber 

of 

ways  exist  to 

create  a 

sequence 

(primary) ; 

(1)  draw  each  frame  on  top  of  the  previous  one; 

(2)  manipulate  (in  a  SPIC  only)  each  frame  i  of  a 
sequence  to  produce  the  next  frame  i+1; 


(3)  create  a  first  approximation  for  process  (2)  by 
using  an  angle  table,  if  one  exists,  describing 
(a  pproxiroa te ly  or  exactly)  the  desired  motion; 
w  create  an  angle  table  from  an  existing  sequence  by 

i 

asking  the  software  to  measure  the  skeleton's  angles 
relative  to  the  picture  (SIIC)  used  as  a  basis  or 
starting  point  for  the  sequence  and  store  it  for  use 
by  other  sequences  so  that  the  basic  motion  of 
RUNNING,  say,  will  always  be  available  for  instant 
application  to  any  similarly  structured  figure  after 
its  first  creation  by  method  (2)  . 

(e)  When  satisfied  with  stage  (d)  -  his  sequences  -  the  user 
goes  to  the  animation  table  to  create  a  "scene"  consisting 
of  the  activities  and  camera  instructions  of  tables  4. 2d 
and  4„2e. 
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The  system 
(sequence,  angl 
instruction)  can 
libraries  as  a 
user  inter-actio 

(a)  two  ver 

-  perm 

-  temp 
to  ve 
onli ne 

(b)  a  syst 
entries  tha 

This  batch 
user  a  first  (an 
when  he  first  in 
saves  considera 
system  his  first 
(as  opposed  to 
tine  significant 
will  be  the  sam 
with  regard  to  t 
probable)  the 
partition  or  gra 

Actually  th 
significant  in 
core  available  t 


will 

be 

designed 

so 

t  h 

at 

any 

piece  of 

da 

ta 

e  table. 

control 

CUI 

ve 

$ 

pi 

ct 

ure 

activity  , 

ca 

me 

r  a 

be 

crea 

ted  off  - 

li 

ne 

a 

nd 

r 

u  n  i 

nto  the 

sy 

st 

em 

ba 

tch 

input  and 

st 

or 

ag 

e 

pr 

cced 

ure  reguir 

i  n 

g 

no 

n. 

This 

implies 

tha 

t 

th 

ei 

e 

shou 

Id  either 

be 

• 

• 

sions 

of  every  library 

anen  t 

(user  has  verified  all 

contents) 

o  L'  a  r  y 

(input  from  batch  run 

which  user 

has 

yet 

r  i  f  y 

by  displaying  and  if 

necessary 

modifying 

or  deleting  for  re-submissi 

on)  ; 

e  m  of 

flags  to  indicate 

batch-read 

library 

t  are 

accordingly  net  verifi 

ed. 

input 

requirement  is  needed 

in  order  to 

give 

the 

d  perhaps  fairly  good)  approximation  to  his  goal 
itiates  the  interactive  creation  phase.  He 
ble  time  since  if  he  is  running  on  a  dedicated 
approximation  will  more  than  halve  the  elapsed 
CPU)  time  and  might  also  reduce  the  processing 


iy 

.  I  n 

a 

mu 

ltip 

rogra 

mnied  e n 

viro 

n  a  e  n  t 

the  gains 

e 

re  gar 

din 

g 

proc 

essor 

time , 

and 

not  a 

s  important 

he 

time 

sp 

en 

t  at 

the 

screen 

un 

less 

(which  is 

co 

mpute 

r 

ha 

s  a 

hea  v 

y  user 

load 

wait 

ing  for  his 

ph 

ic  eg 

uip 

me 

nt . 

e 

a  d  v  a  n 

tag 

es 

of 

batch 

inpu  t 

i 

ma  y 

be  a 

trifle  mere 

so 

me  mu 

lti 

pr 

ogra 

mrning 

si tuat 

ions 

sine 

e  with  less 

he 

a  mou 

n  t 

of 

buf 

fer  s 

wapping 

and 

disk 

I/O  will 
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increase  producing  higher  CPU  use  and  longer  interaction  delays. 

For  the  data  of  figure  4.2  let  us  make  some  estimates  to 
obtain  order  of  magnitude  storage  requir emen ts.  A  number  of 
sequences  involving  large  numbers  of  data  points  might  create 
too  many  curve-length  inches  on  the  display  screen  so  that  even 
buffer  swapping  wouldn't  avoid  serious  flickering  problems.  A 
simple  solution  is  to  display  only  skeletons  whenever  this  is 
possible  (i.e.,  for  all  those  entities  which  are  SPICS)  .  This 
would  accomodate  large  numbers  of  stick-figure  frames  for  rapid 
viewing  and  manipulation.  Tf  the  user  is  concerned  more  with 
viewing  a  finished  (f le shed-out)  product  than  with  manipulation 
he  will  have  the  option  of  storing  blocks  of  data  representing 
consecutive  and  non- manipu latable  display- tuff ers  onto  disk  so 
that  they  can  be  read  down  and  output  to  the  display  device 
every  1/24  seconds  for  a  movie  display. 

It  is  evident  from  table  4.3  that  the  vast  bulk  cf  storage 
is  used  to  contain  the  sequences  (540  out  of  582  K  bytes  =  90$) 
and  their  frames.  This  estimate  would  go  up  considerably  if  the 
user  insisted  upon  examing  a  large  percentage  of  completed 
frames  from  the  film  and  storing  them  for  on-line  viewing  at 
between  1  and  24  f.p.s.  (i.e.,  on  the  IBM  2250).  If  we  assume 
the  user  only  occasionally  puts  on  disk  the  display  buffers  to 
display  a  few  seconds  worth  of  movie,  we  can  store  all  the  data 
on  about  600K  of  disk  for  the  data  or  table  4.3  (which  is  all 
that  is  necessary  for  output  of  the  final  film)  and  if  we  allow 
1  buffer  (8K)  per  final  frame  and  we  want  one  minute  of  film 


UPICS  POINTS 


TITLE  200 

END  40 

CREDIT  60 

STREET  500 

SKY  200 

TREES  1000 

2000 

POINTS  IN  SPICS  POINTS 


BMAN  200 

LMAN  200 

WMAN  200 

CHAOS  1400 

2000 

POINTERS  FOR  SPICS  BYTES 


BYTES 


x  10  bytes/point  =  20,000 


x  10  bytes/point  =  20,000 


BMAN  (16  limbs) 

18 

x  14  = 

250 

LMAN  ( 

"  ) 

250 

WMAN  ( 

m  ii  ^ 

250 

CHAOS  (30  "  ) 

30 

x  14 

400 

1150 

=  1,150 

SEQS 

FRAMES 

PTS/FRAME 

BYTES 

41K 

SKYSEQ 

0 

- 

- 

BMWLK 

20 

250 

50,000 

BWWLK 

20 

400 

80,000 

LWWLK 

20 

400 

80,000 

BMRUN 

10 

250 

25,000 

HAT  IP 

24 

250 

60,000 

PICKUP 

24 

500 

120,000 

PLUGIN 

24 

250 

60,000 

WSTOP 

12 

500 

60,000 

• 

FADE IN 

0 

- 

- 

535,000 

=  535,000 

depth 

x  width  (bytes) 

ANGLE 

TABLES 

(WALK, RUN) 

=  (20 

+  10)  x  17 

=  510 

SEQ 

TABLE 

=  10 

x  19 

=  190 

ACT 

TABLE 

=  17 

x  46 

=  782 

CMR 

TABLE 

=  9 

x  52 

=  468 

1950  =  1,950 

578K 


STORAGE  ESTIMATES  FOR  SCENARIO 


FIG.  4.3 
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stored,  we  need  8K  x  1440  bytes  =  12N  bytes  =  411?  of  disk  space 
on  an  IBH  2314  disk.  We  would  probably  be  happy  to  get  every 
second  frame  (every  1/12  second)  for  20  seconds  [33%  of  our 
"test-mo vie ")  in  one  viewing  and  this  would  only  require  2M 
bytes  and  at  12  frames  per  second  would  not  appear  very  jerky. 


Furthermore , 

2M 

b 

ytes 

would 

a  Iso 

be  a 

cc 

omod 

ated 

easily 

by 

approximate! 

y  V 

3 

of  an 

IBM  23 

11. 

Hew  Blue 

h 

of  t 

he  fi 

lm  is  to 

be 

previewed  wi 

11  o 

bv 

iously 

depen 

d  upo 

n  how  m 

uc 

h  th 

e  f il 

m  is  worth 

to  the  user 

-  wh 

at 

he  is 

willi 

ng  to 

spend 

on 

d  is 

k  spa 

ce  -  and 

is 

not  that  i 

mpor 

t  a 

nt  si 

nee  o 

nly 

cr itica 

1 

fra 

Hies 

such  as 

a 

collision  between  elements  of  two  sequences  need  really  be 
viewed  in  full  before  producing  the  movie  on  film.  A  noteworthy 
statistic  here  is  that  the  entire  data  collection  required  to 
preserve  the  one  minute  film  on  disk  requires  at  most  1/2M 
bytes.  If  all  the  final  frames  of  the  film  were  stored  on  disk 
we  would  require  1440  frames  at  an  average  of  2000  pts  (20K 

t 

bytes)  per  frame  which  gives  29M  bytes  as  the  storage  required. 
Hence  the  data  compression  for  this  instance  (it  will  obviously 
be  highly  variable  depending  entirely  upon  the  kind  cf  film)  is 
.5  to  29  or  1  to  58  i.e.  2%  of  the  final  data  plus  the  software 
system  allows  us  to  produce  the  final  data  (the  film).  Clearly 
this  enables  us  to  store  a  number  of  scenes  (perhaps  for  several 
films)  in  various  stages  of  completion  on  a  disk.  Also  it  means 
that  a  film  can  be  left  on  secondary  storage  for  modification 
and  further  editing  or  simply  for  the  creation  cf  other  copies. 
Finally,  an  estimate  of  man  and  machine  times  and  of  probable 
cost  and  production  times  is  made  using  the  estimates  of  table 
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4.4.  From  these  numbers  several  conclusions  can  be  drawn. 


First  of  all,  in  table  4.5  are  shown  the  best  and  worst 
estimates  of  machine  times  based  on  table  4.4.  Since  one  would 
need  to  view  various  portions  of  the  movie  on  film  before  going 
to  final  output  of  the  whole  film,  this  6  hours  of  machine  time 
would  be  spread  over  possibly  two  or  three  weeks  since  there 
will  be  in  all  probability  a  day's  delay  between  a  computer  run 
and  viewing  of  the  developed  film.  Thus  there  will  be 
approximately  8  or  9  hours  of  intense  man  work  and  6  of  computer 
time  spread  over  several  weeks.  In  practical  terras  this  means 
that  one  man  would  be  working  half  or  full  days  on  the  film  for 
one  to  three  weeks  and  would  use  some  6  hours  of  machine  time. 
The  man’s  salary  might  be  borne  in  mind  as  a  factor  left  out  of 
these  cosidera ticns .  The  computer  cost  ($200/hour  rental,  say) 
would  be  in  the  order  of  $1200  -  which  is  quite  reasonable  even 
by  commercial  animation  standards  and  perhaps  as  lew  as  $270 


(optimistic) 

.  If  the 

machine  is 

multi  programmed 

the  cost 

will 

be  significa 

ntly  reduced 

-  here  the 

estimated  cost 

r eductio 

n  in 

going  from 

elapsed  to 

CPU  time 

is  a  factor 

of  four. 

This 

implies  a  lowest  cost  estimate  of  $270.  Thus  the  order  of 
magnitude  of  the  cost  is  $1000.00  for  one  minute  of  animated 
film.  However  it  must  be  allowed  that  computer  time  estimates 
of  this  sort  could  be  in  error  by  a  factor  of  two.  The  upper 
bound  of  the  cost  is  thus  around  $2000.  Hence  all  we  can  safely 
deduce  is  that  the  film  in  question  is  within  reason 


financially 


ENTITY 

MAN  TIME 

ENTITY 

MAN  T 

TITLE 

1. 

DTLE 

5.0 

END 

.5 

DFDE 

5.0 

CREDITS 

1. 

DSLV 

5.0 

STREET 

15. 

BWLK 

5.0 

SKY 

3. 

WSTD 

5.0 

TREES 

10. 

RHAT 

5.0 

UP ICS  = 

30. 

TURN 

5.0 

BMAN 

30. 

CWLK 

5.0 

LMAN 

30. 

LSTD 

5.0 

WMAN 

30. 

PLUG 

5.0 

CHAOS 

60. 

SMIL 

5.0 

SPICS  = 

150. 

CRMB 

5.0 

SKYSEQ 

2. 

EMRG 

5.0 

BMWLK 

30. 

BMRG 

5.0 

BWWLK 

30. 

LWLK 

5.0 

LWWLK 

30. 

END 

5.0 

BMRUN 

20. 

CRDT 

5.0 

HAITI  P 

30. 

ACTIVITIES  = 

85.0 

PICKUP 

30. 

PLUGIN 

30. 

WSTOP 

20. 

FADE IN 

2. 

SEQUENCES  = 

224. 

There  are  9  camera  instructions  which  might  take  about  1  to  3  minutes 
each  to  set  up.  Thus  CAM. INST  =  9.  to  27. 


Time  estimates  for  the  creation  of  pictures,  sequences  and  activities  for  a 

scene.  (All  times  not  specified  are  in  minutes). 


FIG.  4.4 


PROBABLE 

MACHINE 

TIMES 

MAN  TIME 

OPTIMISTIC 

WORST  CARE 

UPICS 

30. 

0. 

0. 

SPICS 

150. 

5. 

10. 

SEQS 

224. 

50. 

224. 

ACTIVITIES 

85. 

20. 

85. 

CAM. INSTNS 

27. 

5. 

27. 

516. 

80. 

346. 

(=8.5  hrs.) 

(=  6hrs.) 

The  "worst  case"  corresponds  to  the  use  of  a  dedicated  machine  (no 
multiprogramming)  and  the  optimistic  case  corresponds  to  a  multiprogrammed 
environment  in  which  it  has  been  assumed  that  at  most  25%  of  the  elapsed 
time  is  CPU  or  I/O  time.  In  both  cases  UPICS  and  SPICS  are  prepared  off¬ 
line  for  batch  input  and  are  then  interactively  "touched  up". 


MAN  AND  MACHINE  TIME  ESTIMATES  (MINUTES  UNLESS  OTHERWISE  INDICATED) 


FIG.  4.5 
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CHAPTER  5 


CONCLUSIONS 

At  this  stage  implementation  should  begin.  With  reference 
to  figure  1  of  appendix  A  the  paths  which  should  be  coded  first 
are  those  which  allow  creation  of  sequences.  A  significant 
proportion  of  time  spent  in  this  system  will  be  either  here  or 
in  scene  creation  (activities  and  camera  instructions)  and  test 
procedures  will  be  required  to  seek  out  the  most  efficient 
interaction  procedures  by  which  sequences  can  be  created.  Cnee 
workable  routines  exist  for  the  creation  of  sequences, 
procedures  for  the  more  straightforward  business  of  picture  and 
structured  picture  manipulation  can  be  added  as  the  second 
stage.  The  third  stage  in  building  the  system  will,  from  this 
vantage  point,  be  the  scene  handling  routines  (of  which  the  film 
creation  routines  will  probably  be  an  extension) .  Finally  the 
system  could  be  refined  by  addition  of  a  routine  library 
designed  to  create  or  generate  mathematical  curves,  special 
effects  etc. ,  and  programs  which  manipulate  pictures,  structured 
pictures,  sequences,  activities  or  even  entire  scenes. 


In  building  up  the  system  as  suggested,  many  changes  and 
improvements  will  doubtless  arise.  A  powerful  and  flexible 
animation  system  is  more  likely  to  evolve  by  concentration  on 
software  (data  structures  and  interaction  procedures)  than  by 
improvement  of  specialized  peripheral  devices.  Addition  to  the 
system  of  devices  such  as  video  tape,  TV  cameras,  color  TV 
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display  tubes  and  video  rate  disk  drives  etc,,  in  additiom  to 
increasing  the  potential  of  the  animation  system  utilizing  them, 
also  increases  the  need  for  elegant,  flexible  and  extensible 
software  to  enable  the  user  to  take  full  advantage  of  them. 


Experimental  programs  can  be  profitably  written  at  this 
stage  for  the  devising  of  efficient  and  simple  methods  for 
sequence  creation  using  both  articulated  and  non  articulated 
pictures.  An  experimental  program  was  written  to  test  the  area 
of  sequence  creation  and  display.  This  is  a  critical  area  in 
which  more  work  needs  to  be  done  since  the  experimental  routines 
indicate  that  the  interaction  methods  will  determine  whether  the 
system  is  convenient  and  practical  for  the  animator  to  use.  The 
angle  table  approach  has  been  tried  and  used  with  a  routine 
which  creates  smooth  joints  at  sub  picture  intersections. 


Procedures  will  have  to  be  coded  for  the  operations  of  FKTS 
2,5,9,10,14,15,17,18  and  the  system  control  program.  Judging  by 
experience  at  the  University  of  Toronto  with  the  A  FT A  system 
(24)  the  control  program  will  require  a  resident  portion  of  20K 


to 

30K  bytes 

.  T 

he  other 

P 

rocedures  will 

number 

around 

100  '  and 

will  range 

from 

a  few  1 

in 

es  of  FORTH AN 

code  to 

several 

hundred . 

If 

we  assume 

an 

average 

of 

50  lines  per 

rout,  in  e 

and 

ICO 

routines 

we 

need  to 

co 

de  5K  1 

in 

es  of  FORTRAN. 

Assume 

15 

lin 

es  of  bug 

free  code  per  man  per  day  and  we  can  hope  for  15*20=300  lines 
per  leonth.  Since  the  figure  of  5K  is  pessimistic,  when  the  time 
to  code  the  control  program  is  added  in,  the  programming  time 
will  be  at  most  two  years  (allowing  3  to  6  months  for  the 


77 


control  program)  • 
would  take  no  less 


I  would  expect,  at  the  other  extreme, 
than  one  man  year. 


that  it 


The  routines  other  than  the  control  and  a  few  commonly  used 
ones  will  have  to  be  brought  into  core  upon  request  in  a  systeta 
of  overlays  in  order  to  free  the  maximum  core  for  arrays.  For 
example,  in  a  200K  machine  we  would  want  to  keep  the  total 
proram  size  under  lOOK-judging  by  experience  with  AHTA  on  an  IBM 
360/44. 


Thus 

with 

one  or 

two 

man  years  o 

f  programming 

it 

is 

possible 

to 

produce 

thi  s 

sytem.  The 

result  would 

be 

an 

animation 

aid 

designed 

from 

the  outset  to 

handle  all  aspects 

of 

animating  articulated  figures. 
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APPENDIX  A 


USER  INTERACTION  PROCEDURES 


One  of  the  critical  design  areas  of 
system  is  that  of  the  man  machine  in 
user  input  his  decisions,  data  and  re 
machine  present  the  user  with  possible  a 
point  in  the  creation  of  a  movie?  In 
endeavour  to  give  an  explanation  of  the 
interacts  with  this  system. 

Figure  1  gives  a  flow  chart  showing 
from  one  screen  display  (command  me 
preview,  library  content  list  etc.)  to  t 
the  particular  request  he  inputs  to  the 
pen,  function  key  board  (FKB)  or  typewri 
to  25  show  the  detailed  screen  formats 
display  formats  in  fig  1.  These  formats 
of  the  screen  layout,  commands  which  ca 
pen  selection  from  a  menu  and  commands  w 
means  of  the  function  keys. 


any  computer  animation 
teraction.  How  does  the 
quests?  How  does  the 
lternatives  at  any  given 
this  section  I  shall 
manner  in  which  the  user 
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When  the  user  signs  on  he  is  asked  to  provide  some 
initialization  data 

-  ensure  that  the  libraries  are  mounted 

-  put  on  the  appropriate  tapes,  if  any 

-  set  up  the  "lens-dimensions*'  to  be  compatible  with  the  output 

(16mm,  35mm,  TV  etc.).  He  then  sees  format  1.  He  may,  at  this 
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format,  elect  to  have  ever 

sent  out  to  the  H/F  plott 

normal  M/F  output,  the 
leading  up  to  the  M/F 

This  is  a  very  time-consum 
should  not  use  it.  It  wil 

(1)  debugging; 

(2)  explanation  of  the  sys 

scenes  we  will  have  a  fi 
in  its  production.  Such  a 
devising  more  efficient  in 
plausible  option  is  simply 
1  that  all  screen  inte 

(L/P) .  The  former  might  p 
necessity,  for  tuning  and 


y  screen  display  (format  included) 
er  as  well  so  that  upon  request  of  the 
screen  changes  of  the  interactions 
output  will  precede  the  norifal  output, 
ing  option  and  the  default  options 
1  be  useful  for  the  following: 


tern's  use  tecause  in  addition  to  f 
lm  of  the  screen  interactions  regu 
record  will  be  highly  useful 


teract ion 
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As  seen  by  figure  2  the  user  now  decides  whether  he  wishes 
to  work  on  sub-pictures  (UPICS)  structured  pictures  (SPICS) 
sequences  (SEQS)  ,  scenes  (SCNS)  or  entire  film  strips  (FLf!S) 
or,  if  he  has  returned  to  format  1  (FMT1)  from  a  deeper  level  in 
the  flow  chart  of  fig.1  then  he  may  wish  to  end  the  session.  In 
all  of  the  formats  shown,  a  dash  to  the  left  of  a  command  means 
that  the  user  light  pens  this  dash  to  enter  the  command.  Dashes 
to  the  right  indicate  the  user  is  to  type  in  appropriate  data 
(which  will  be  displayed  in  these  locations  prior  to  the  user's 
requesting  execution) . 
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A  numbered  circle  to  the  left  of  a  command  means  that  the 
user  must  hit  the  appropriate  push  button  on  the  FKE  to  initiate 
this  command.  The  command  RETURN  which  appears  on  all  displays 
(either  on  a  screen  menu  or  the  FKB)  will  return  the  user  to  the 
display  which  preceded  the  current  display  i.e.,  return  the  user 
to  a  higher  level  in  the  flow  chart  of  fig. 4.1. 

HI!ICS..  The  user  can  manipulate  the  UPIC  library,  alter  the 
UPICS  in  core  and  choose  those  which  he  wishes  to  display  and 
from  those  displayed,  choose  any  one  to  modify  or  delete.  To 
help  him  he  can  view  the  list  of  UPICS  in  core  (see  FMT  2  )  cr 
in  the  library  (FMT3)  .  The  picture  display  occurs  in  FMT4  at 
which  point  he  can  draw,  redraw  or  delete  any  UPIC  which  is 
displayed. 

SFICS^  In  FMT  6  the  user  has  the  power  to  read  SPIC  arrays 
from  the  library  etc.  and  in  FMT8  he  can  display  the  UPICS  of  a 
SPIC  (and  hence  the  I/O  routines  of  the  SPIC  procedures  use 
those  of  the  UPIC  procedures  as  a  subset)  and  change  the 
structured  picture  and  add  a  SPIC  or  delete  it.  If  he  wishes  to 
alter  a  sub-picture  he  may  do  so  and  hence  all  of  UPIC  commands 
in  FKT4  are  available  in  FMT8. 

If  he  elects  in  format  1  to  deal  with  sequences  the 
user  is  granted  the  power  to  select  (or  create)  a  sequence  for 
modification,  display  its  individual  frames  (up  to  16  of  them  at 
a  time)  as  in  format  12.  Here  each  of  the  Fi  contains  a  frame 
from  the  sequence  so  that  up  to  16  at  a  time  may  be  viewed 
simultaneously  for  comparison  on  a  small  scale.  The  frames  are 
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put  into  area  W  for  crea tion/modif ication.  The  user  may  also 
display  several  sequences  at  a  time  to  enable  and  simplify  the 
task  of  creating  a  transition  or  continuation  sequence  X  such 
that  given  sequences  A  and/or  E  then  AX  or  XE  or  AXB  are 
continuous  sequences  of  unbroken  motion.  To  save  space  both  in 
the  display  buffer  and  in  the  main  storage  area  the  user  will 
usually  need  to  work  with  skeletons  until  he  is  ready  to  view 
the  sequence  in  motion. 

For  step-thru  or  continuous  viewing  of  the  motion  thus 
created,  he  goes  to  the  display  in  format  13.  If  satisfied  he 


stores 

the 

sequence  if  not 

he  returns  to 

FMT  12 

and  repeats 

the 

cycle 

of 

modif icat ion 

and  viewing. 

The 

details  of 

the 

modifications  should  be  obtained  from  the  format  descriptions 
(10,11,12,13)  and  the  discussion  on  the  structure  of  sequences 
in  chapter  3. 

Should  he  elect  the  scene  option  of  format  1  then  he  gets 
to  control  the  parameters  of  the  appropriate  activity  and  camera 
instruction  tables  and  in  effect  he  looks  down  thru  the  lens  of 
the  camera  at  a  virtual  animation  table  whose  rest  (0,0) 
coordinates  are  centred  in  the  initial  viewing  area.  He  may 
look  thru  the  lens  in  "free”  mode  or  "driven”  mode.  The  former 
implies  freedom  to  adjust  the  camera  independently  of  the  camera 
instructions,  the  latter  involves  using  the  camera  instruction 
of  frame  i  to  view  the  ith  frame  set-up. 

Normally  all  the  user  will  manipulate  or  examine  is  the 
layout  of  envelopes  (empty)  on  the  table.  He  can,  at  the 
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expense  of  extra  computing  resources,  view  the  contents  of 
envelopes  as  well.  This  will  be  necessary  only  for  certain 
critical  alignment  situations  where  the  action  of  two  activities 
must  be  closely  inter-related  (eg. ,  two  figures  making  contact) . 

FLMS^  And  finally,  a  straightforward  set  of  commands  must 
be  provided  to  put  films  out  onto  the  micro-film  plotter  (these 
commands  are  also  accessible  from  the  scene  creation  commands  of 
format  #16:  FMT 1 6 )  and  to  allow  the  user  to  group  sets  of  stored 
scenes  into  films  under  a  chosen  film  name. 


FLOW  CHART  OF  CONTROL  PATHS  AMONG  FORMATS 


FIG.  A. 1 


FMT  1 


-  UPICS  [2] 

-  SPICS  [6] 

-  SEQS  [10] 

-  SCENES  [14] 

-  FILMS  [19] 

-  END  SESSION 

-  RECORD  ALL  INTERACTIONS 


HERE,  THE  USER  SELECTS  ONE  OF  6  MAJOR  AREAS  OF  OPERATION 


FIG.  A. 2 


FMT  2 


-  READ  FROM  UPIC,  LIB  ------  INTO 

-  WRITE  ------  INTO  UPIC. LIB  AS  - 

-  DELETE  UPIC. LIB  [3] 

-  CREATE  UPIC  :  NAME - -  -  PTS  - 

-  DISPLAY  UPIC  ON  2250  [4] 

-  RETURN  [1] 

-  OPERATORS /GENERATORS  [5] 

-  DELETE  UPIC  IN  CORE  (SELECT  BELOW) 

UP ICS  IN  CORE 

NAME  #PTS  NAME  #PTS  NAME  #PTS 

-  XXXX 

-  XXXX 

-  XXXX 


PROCEDURES  FOR  DEALING  WITH  UPICS  ON  DISK  AND  IN  CORE 


FIG.  A. 3 


« 


FMT  3 


-  RETURN  [2] 


UP I C. LIB  LIST 


ZZZZZZ  ZZZZZZ  -ZZZZZZ 

ZZZZZZ 

ZZZZZZ 


DISPLAY  OF  THE  CONTENTS  OF  UPIC.LIB 


FIG.  A. 4 


<3)  ©  0  0 
©  ©  ©0  ®  0 
0  ©  ©@  @  0 
0  0  0  0  0  0 
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The  FKB  is  used  to  input  the  following  user  requests: 

BUTTON 

0  RETURN  [2] 

1  RETURN  [3] 

4  ADD  POINTS 

5  DELETE  POINTS 

6  ADD  LINES 

7  DELETE  LINES 

i 

8  MOVE  POINT 

11  DELETE  HINGE 

12  ADD  HINGE 

13  HINGES  VISIBLE 

14  HINGES  INVISIBLE 

DISPLAY  AND  MODIFY  A  PARTICULAR  UPIC 


The  screen  is  used 
to  hold  a  display 
of  the  selected  UPIC 

! 

I 

i 


i 


FIG.  A. 5 


FMT  5 


This  display  will  consist  of  a  list 
(menu)  of  functions  and  subroutines  - 
some  of  them  user  written  -  to 
generate  and  manipulate  line  drawings 
and  text. 


-  RETURN 


FUNCTION  AND  SUBROUTINE  MENU 


FIG.  A. 6 
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-  READ  FROM  SPIC.LIB  -  - - INTO - 

-  WRITE  INTO  SPIC.LIB - FROM - 

-  DELETE  FROM  SPIC.LIB  [7] 

-  DELETE  SPIC  IN  CORE  (CHOOSE  ONE  BELOW) 

-  CREATE  SPIC  -  -  FROM  (CHOOSE  THE  COMPONENTS  BELOW) 

-  DISPLAY  SPIC  (2250)  [8] 

-  RETURN  [1] 

-  OPERATORS /GENERATORS  [5] 


SPICS  IN  CORE 
XXXXXX  XXXXXX 


UPICS  IN  CORE 
XXXXXX  XXXXXX 


MENU  OF  COMMANDS  TO  MANIPULATE  SPICS  IN  CORE  AND  ON  DISK 


FIG.  A. 7 
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-  RETURN 

SPIC.LIB 

XXXXXX 


[6] 

LIST 


XXXXXX  XXXXXX  XXXXXX 

•  •  • 

•  •  • 

•  •  • 


CONTENTS  (NAME  INDEX)  OF  SPIC. LIBRARY 


FIG.  A. 8 


FMT  8 


i 

Menu  3  SPIC 

area  *  display  area 

l 

l 
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Menu  will  be  as  follows 

-  SELECT  PIC(S) 

-  CLEAR  PIC(S) 

-  RECOMPOSE  UPIC  (PEN  IT) 

-  CREATE  UPIC  ------  WITH  -  -  -  PTS 

-  ATTACH  (PEN) - - TO  (PEN)  -  - 

-  DETACH  (PEN) - FROM  (PEN)  -  - 

-  ADD  SPIC  [6] 

-  ADD  UPIC  [2] 

-  DELETE  PIC 

-  SCALE  ( -  ) 

-  TRANSLATE  ( - ) 

-  ROTATE  (---, - , - -) 

-  PIVOT  ROTATE  ( - ) 


PIC 

TYPE 

ACT. PTS 

MAX. PTS 

-  xxxxx 

-  xxxxx 

S 

U 
* . 

• 

• 

• 

nn 

• 

t 

mm 

(Ah  asterisk  means 
"father"  or  point 

the  picture  has  no 
of  attachment) 

[The  FKB  is  the  same  as  for  FMT4] 


DISPLAY  AND  MODIFY  A  PARTICULAR  SPIC 


FIG.  A. 9 


FMT  9 


This  display  will  simply 
present  the  user  with  the 
decisions  required  by  the 
routine  he  selected  in 
FMT  5. 


FUNCTION  PARAMETER  DISPLAY/REQUEST 


FIG.  A. 10 


FMT  10 


-  RETURN  [1] 

-  READ  FROM  SEQ.LIB - INTO 

-  WRITE  INTO  SEQ.LIB  - - -  INTO 


-  DELETE  FROM  SEQ.LIB  [11] 

-  DUMP  SEQ  TABLE  ONTO  L/P  FOR  SCENE  - 

-  DUMP  SEQ.LIB  INDEX  ONTO  L/P 

-  OPERATORS/GENERATORS  [5] 

-  SELECT  SEQS  FOR  MOVIE  DISPLAY  (CHOOSE  BELOW) 

-  SELECT  SEQ  FOR  MODIFICATION  :  FRAME  ---  IN  SLOT  --  TO  - 

-  GO  TO  MOVIE  OF  SEQ  [13] 

-  GO  TO  MODIFY  SEQ  [12] 

-  CLEAR  SEQ  FROM  MOVIE  DISPLAY 

-  CLEAR  SEQ  FROM  MOD.  DISPLAY 

-  SELECT  ACTIVE  SEQ  FOR  MODIFICATION 


SEQUENCES  IN  CORE 


ORDER  OF 

NAME  TYPE  #FRAMES  DISPLAY 

-  XXXXXX  XXX  nn  n 


-  NEW  PSEQ  *  - 

-  NEW  PSEQ  -  - 

-  SSEQ  -  -  -  - 

-  CSEQ  -  - 


-  :  PIC  =  - 

-  -  (S  or  T)  =  PSEQ - (FROM  - 

-  =  SEQ  -----  INTERP  =----- 

£o=--£F=--NC=-- 


MANIPULATE  SEQUENCES  (CORE,  DISK) 


-  TO  -  -) 

"  "  "  >  " 


FIG.  A. 11 


FMT  11 


NAME 

-  xxxx 


-  RETURN  [10] 
SEQ.LIB  LIST 

TYPE  #FRAMES 
XX  XX 


DISPLAY  SEQUENCE  LIBRARY  INDEX 


FIG.  A. 12 


FMT  12 
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.  ;•  .  ?  • 

i 

F8 

F9 

• 

: 

• 

• 

!  1 

.  i  .  j 

I  ! 

I  j 

?  j 

Menu  Work  display 

area  \  area 


-  PROTM 

-  SCALEM 

-  TRANSM 

-  ROTM 

-  WORK  F(I) 

-  F(I)  WORK 

-  CLEAR  F(I),  I  =  --  TO  -- 

-  PIC - INTO  WORK 

-  SHIFT  (-LEFT  or  -RIGHT)  BY  -- 

-  MOVIE  OF  SEQ  [13] 

-  RETURN  [10] 

*  f  -  REPLACE  PIC  (PEN)  OF  SEQ  (CURRENT)  BY  PIC  (PEN)  OF  SEQ - 

)  -  ADD  PIC  (PEN)  OF  SEQ  -  TO  PIC  (PEN)  OF  SEQ  (CURRENT) 

L  -  DELETE  PIC  (PEN)  OF  SEQ  (CURRENT) 


FROM  FRAME  --  TO  --  FOR  --  CYCLES 

i 

SUB  PICTURES  (OF  CURRENT  SEQ  XXXXXX) 


NAME 

NAME 

NAME 

-  xxxx 

-  XXXX 

-  XXXX 

-  xxxx 

• 

• 

-  xxxx 

• 

• 

-  xxxx 

• 

• 

DISPLAY  AND  MODIFY  A  PARTICULAR  SEQUENCE 


FIG.  A. 13 
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FMT  13 


SCREEN  USED  FOR 
MOVIE  DISPLAY  OF 
SEQUENCE (S) 


FKB 

COMMAND 
CONTINUOUS 
STEP-THRU 
ADVANCE  1  FRAME 
REVERSE  1  FRAME 
GO  TO  [1] 

GO  TO  [10] 

GO  TO  [12] 

NO  OUTPUT  TO  M/F  PLOTTER  (DEFAULT  OPTION) 
OUTPUT  EACH  FRAME  CHANGE  TO  M/F  ALSO 


MOVIE  DISPLAY  (VIDEO  DISPLAY  DEVICE)  OF  A  SEQUENCE 


FIG.  A. 14 


FMT  14 


READ  FROM  SCN.LIB - INTO - 

WRITE  INTO  SCN.LIB  -  FROM  - 

DELETE  FROM  SCN.LIB  [15] 

DUMP  SCN  TABLES  ONTO  LIP  FOR  SCN  - 

DUMP  SCN  LIST  ONTO  L/P 
DISPLAY  SCN. LIST  [15] 

RETURN  [1] 

NEW  SCN  =  - 

DISPLAY  SCN  (2250)  - 

-  OVERVIEW  [16] 

-  STEP  THRU  MOVIE  [16],  FREE  VIEWING?  - 

-  CONTINUOUS  MOVIE  [16] 

-  CONTENTS  OF  ENVELOPES 

-  EMPTY  ENVELOPES 

-  DISPLAY  CC 

-  GO  TO  SCN. DISPLAY  [16] 

INSERT  SCN  -  AFTER  (PEN) 

NEW  SCN  NAME  =  - 

DELETE  (PEN) 

CHANGE  £  /f  (PEN  ACT) 


SELECT  ACT.  FOR 


ACTIVITIES 

CAMERA 

INSTNS 

SHOWING  IN  SCN 

name 

fo  fn 

name 

fo 

fn 

-  ALL  PRESENT 

-  CLEAR  ALL 

XXXXX 

NN  NN 

-  XXXX 

NN 

NN 

-  DELETE  (PEN) 

-  ADD  (PEN) 

-  SELECT  (PEN) 

FOR  MOD  IN  [16] 


SCENE  MANIPULATIONS 


FIG.  A. 15 


FMT  15 


-  RETURN 

SCN.LIB  DATA 


DISPLAY  OF  SCENE  LIBRARY  INDEX 


FIG.  A. 16 


FMT  16 


SCENE 

DISPLAY 

AREA 


0.  DRAW  LENS  MASK 

("FROM  --  TO  ON  SCREEN) 


1.  SET  SCALE 

("SCALE  = - "  ) 

2 .  ROTATE  CAMERA 

("ANGLE  = - "  ) 

3.  TRANSLATE  CAMERA 

("penA,  penB"  ) 


4.  START  MOVIE  or  ADVANCE  1  FRAME 

5.  STOP  MOVIE  or  REVERSE  1  FRAME 

6.  RETURN  [14] 

7.  USE  CURRENT  CAMERA  PARAMETERS 

FOR  Eo  "Cl  =  ACT  =  ---" 

8.  USE  CURRENT  CAMERA  PARAMETERS 

FOR  E„  "Cl  ---  ""ACT  =  ---" 

F 

9.  ADD  TCC  ("TCC  =  ---") 

10.  MODIFY  TCC  ("TCC  =  - ") 

11.  DELETE  TCC  ("TCC  =  - ") 

12.  CLEAR  TCC  ("TCC  =  ---") 

13.  CONNECT  TCC  TO  ACT 

("TCC  =  -  ACT  ---") 

14.  DISCONNECT  TCC  TO  ACT 

("ACT  =  ---"  ) 

15.  E - >Eo 

("ACT  =  ---"  ) 

16.  E - »EC 

F 

("ACT  =  ---"  ) 


®  ®  ©  © 


18.  ROTATE  E 

19.  TRANSLATE  E 

20.  DRAW  E 

21.  DELETE  E 

22.  INDEPENDENT  INTERP  OF  SCALE  [17] 

23.  "  "  "  ROTATION  [18] 

24.  SELECT  PIVOT  POINT  ON  E  (PEN) 


25. 

SELECT  CONTACT 

POINT  ON  Eq  (PEN) 

26. 

Eq  (CURRENT)  = 

Ep  (PREVIOUS) 

"E  (ACT - ) 

0 

=  Ep  (ACT  — -)" 

27. 

FNq  (CURRENT) - 

1  =  FNq  (PREVIOUS) 

"FN  ---  =  FN„ 

- +1" 

o 


28.  | 

29 .  > 

30. 


NOT  USED 


DISPLAY  AND  MODIFY  A  SCENE 


FIG.  A. 17 
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FKB  Functions 

DRAWING  THE  NEW  SCALE  CONTROL  CURVE  (SCC) 

NAME  (TYPE  IN  ON  RESPONSE  TO  SCREEN  QUEUE)  NEW  SCC 
DISPLAY  LIST  OF  SCC  NAMES  ON  SCREEN  (LIB.) 

CLEAR  CURRENT  SCC's  POINTS  (ALL) 

DELETE  POINTS  FROM  SCC 

DELETE  NAMES  FROM  SCC  LIST  (AND  HENCE  FROM  LIB.) 
RETURN  [16] 


DISPLAY  AND  MODIFY  AN  SCC 


FIG.  A. 18 
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FKB  Functions 
DRAW  POINTS  OF  RCC 

NAME  (IN  RESPONSE  TO  SCREEN  QUEUE)  NEW  RCC 
DISPLAY  LIST  OF  RCC  NAMES  ON  SCREEN 
CLEAR  ALL  POINTS 
DELETE  INDIVIDUAL  POINTS 

DELETE  RCC  NAMES  FROM  LIST  (AND  HENCE  LIB.) 
RETURN  [16] 


DISPLAY  AND  MODIFY  AN  RCC 


FIG.  A. 19 
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RETURN  [1] 

READ  FROM  FLM.LIB - INTO - 

WRITE  FROM  FLM.LIB  -  ONTO  - 

DELETE  FROM  FLM.LIB  [20] 

DUMP  FLM.LIB  ONTO  L/P 
DISPLAY  FLM.LIB  NAMES  ON  2250 
NEW  FILM  =  - 

DISPLAY  SCENE  NAMES  OF  FILM  - [15] 

ADD  SCENES  (TYPE) 

DELETE  SCENES  (PEN) 

INSERT  SCENES  (PEN  PREVIOUS) 

DISPLAY  FILM 

STEP-THRU  (2250)  FROM  ---  TO  ---  BY  ---  [21] 
CONTINUOUS  (2250) 

"  (M/F) 

"  (BOTH) 

SELECTED  FILM  IS  XXXXX 

SCENES  LENGTH (SECONDS)  LAST  FRAME 


-XXXXX  TT 


NN 


MANIPULATE  FILMS 


FIG.  A. 20 
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RETURN 


FLM.LIB  NAMES 

SCENES 

CONTAINED 

-XXXXX 

YYYYY 

YYYYY 

YYYYY 

YYYYY 

-XXXXX 

YYYYY 

YYYYY 

DISPLAY  FILM  LIBRARY  INDEX 


FIG.  A. 21 
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IF  "M/F"  ONLY  MODE, 
THEN  SCREEN  CONTAINS 
"M/F  OUTPUT  NOW" 


0  RETURN  [19] 

0  START  MOVIE  (ADVANCE  1  FRAME) 

0  STOP  MOVIE  (REVERSE  1  FRAME) 


DISPLAY  FILM 


FIG.  A. 22 


